scribd
/
scribd.github.io
mirror of https://github.com/scribd/scribd.github.io
1
0
Fork 0
Code Issues Releases Wiki Activity

Copy edits and removing some redundant statements/prose

This commit is contained in:
R Tyler Croy 2020-03-20 16:36:53 -07:00
parent 5c07eb1111
commit ab2eaee608
No known key found for this signature in database
GPG Key ID: E5C92681BEF6CEA2
1 changed files with 58 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

104
_posts/2020-03-25-reclaiming-story-points.md
View File

@ -13,55 +13,62 @@ improve with company growth we have needed to reevaluate a number of practices
such as utilizing **story points**.
[Story points](https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/) in agile are a way of estimating how much work something is. They
are deliberately _not_ exact functions of difficulty and time because you never
are deliberately _not_ exact functions of difficulty and time. You will never
know all the complications when you start a project. Even something as simple
as making dinner can get tripped up by a missing ingredient or a dirty pot, so
too can software delivery. The issue that we ran into is that we rolled it out with an
early set of folks who were clear on it and how to use it but we didn't
socialize that change both across the organization and upwards.
too can software projects. Our first foray into story points was done with a
small group of folks who had a good understanding of the practice and its
implementation. When rolling story points out across the broader organization
we made a couple mistakes, namely that we didn't socialize that change both
across the organization and _upwards_.
It's very easy to say 'that's 8 points' and hard to translate that out into a
meeting where we cover all the projects in flight with a target and actual done
date attached to it. Business gets attached to those dates and makes plans
using them and then a team comes back with a slip and suddenly everyone is
upset. The team is upset because they knew that 8 points was an estimate that
accommodated a period of time in which they could deliver. Management is upset
because things slipped and now they feel things are late when that was never
really going to be the time anyway.
It can be very easy to say "oh, that's 8 points" in a planning meeting, but
that's hard to translate into a meeting where we cover **all** the projects
currently in flight, especially when trying to arrive at a target and actual
done date for the project or task. We had a tendency to get attached
to those dates, making plans across the organization. Then when a team would
slip on that translated schedule, everybody would get upset!
The team would be upset because they _knew_ that "8 points" was an estimate
that accommodated their internal understanding of a period of time. Management
would be upset because things slipped from their translated schedule which was
itself based on a global translation of story points into time.
<center>
<img src="/post-images/2020-03-story-points/stop.png" alt="Stop!" align="center"/>
(<em><a href="https://publicdomainvectors.org/en/free-clipart/Stop-speech-bubble/82516.html" target="_blank">source</a></em>)
</center>
So story points got banned from the management meeting. Project managers could
now only speak to deadline dates and added language that mentioned things like
So..story points got banned from the management meeting. Project managers could
then only speak to deadline dates and added language that mentioned things like
'best estimate' and 'could slip' to hedge around the fact that software
development isn't an exact science as much as we would like it to be. We still
talked about them and used them in the team meetings but it was a verboten term
outside that space which led to its own tensions.
development isn't an exact science. We still talked in story points in our team
meetings but it was a verboten term outside that space which led to its own
tensions.
One of the related reasons story points got banned was the nature of the
imprecision. Yes, points should be specific to the team but our velocity was
One of the other reasons story points got banned was the nature of the
imprecision. _Yes_, points should be specific to the team but our velocity was
completely unpredictable from team to team. Sometimes it would be 20 points and
others 50. Regression passes were sometimes included and pointed, sometimes
they weren't. It started with a team of more junior developers and QA that had
one of the aforementioned velocity issues. We asked them how big a 3/5/8 was
and got a different answer from each of them. We had found the underlying
problem that had given story points a bad name.
problem that had given story points a bad name!
It was time to go back to basics. We had a story pointing workshop with that
team that already had strong communication and was a safe space to talk through
in the retrospectives why they were all over the map. Some of it was because
It was time to go back to basics. We had a "story pointing workshop" with that
team. The team already had strong communication and had a safe space, a
retrospective, to talk through the issue of why their understanding was all
over the map.
Some of it was because
they were more junior and were less likely to know where the problems were in
the code base but some of it was because we had just assumed that everyone knew
the code base, but some of it was because we had just assumed that everyone knew
what a 5 might entail. An hour later we had a white-board covered in notes with
items under each number in the Fibonnaci sequence. Items that included things
from each of the developers, QA and the chapter lead (in this case a senior
technical developer). We did it again with the entire mobile QA team, sharing
from each of the developers, QA and the squad lead (in this case a senior
developer). We did it again with the entire mobile QA team, sharing
some of the findings after we first did the brainstorm fresh, sharing where
that team had seen points falling. It turned into a wiki page that was shared
within the project management team and spread from there.
within the project management team, and it spread from there.
<center>
<img src="/post-images/2020-03-story-points/efforts.png" alt="Different efforts are different!" align="center"/>
@ -71,25 +78,30 @@ within the project management team and spread from there.
We were clear throughout this process that points were still team specific and
that none of this was to be taken as hard and fast rules but it gave teams a
place in which to start the conversation and have common ground. We don't want
to make it sound like all the teams were terrible at pointing or having
reliable velocity but the variability often exceeded 10% which made it hard for
management to show trust in our date estimates. It became easier for teams to
have more accuracy which led to more trust in deadlines which in turn led to a
way where we could talk about story points again.
to make it sound like all the teams were terrible at making story point
estimates, or bad having reliable velocity, but the variability often exceeded
10%. Larger variance made it hard for management to show trust in our date
estimates. With some common guidelines, it became easier for teams to have more
accuracy, which led to more trust in deadlines, which ultimately gave us a way
to talk about story points again.
When the deadlines shifted to being reliable within a day or two it was less
charged of a conversation to mention that we'd done a good breakdown on the
work and it was reflected in Jira that way. We do a project lifecycle that
When the deadlines shifted to being reliable within a day or two, the
conversation wasn't as charged since somebody could show the
good breakdown on the
work, which was also reflected in Jira. We operate a project lifecycle that
starts with a product brief, goes through design iterations, and then goes into
story breakdown and sizing. Only after those steps are done do we 'put hands on
keyboard' and start writing software. It turns out people really do need time
to think through the problem before solving it. Again, this isn't perfect. We
still have tech debt and brittle code. We will always have people who under or
over estimate work - which is why we use points.
story breakdown and sizing. Only after those steps are done do we "put hands on
keyboard" and start writing software, usually with pretty solid estimates. **It
turns out people really do need time to think through the problem before
solving it!**
Our approach isn't perfect of course. We still have spots of tech debt and
brittle code. We will always have people who under or over estimate work, but
that's why we use story points.
The initial reaction to story points was justifiable, but we continued to
iterate on the problems we ran into with the original implementation of story
points. Finally, by bringing up the concept of "velocity" and demonstrating how teams
were getting more reliable in their estimates with story points, we were able
to show management that the method was worth trusting.
With bringing in words like velocity and showing that over time teams were
getting more reliable in their estimates we were able to show management that
the method was worth trusting and we were again able to use the term story
points in our meetings with them. The reaction to the phrase early on was
justifiable from the point of view and what we did to fix the underlying issue
led to us being able to reclaim it.