Story Points
Glenn
like to get some advice on from this group. We have been practicing
Scrum successfully for many years now. For one reason or another, our
Development team has struggled to find a meaningful place for story
points in our process. At some point, the validity of the points
breaks down because the stories change in size and scope as they move
through our process.
The majority of our product back log is comprised of epics. We
currently have assigned story points to all of these. As it comes
closer to time for a story to get worked on, they go through UX
research and design, at which point the analysts and developers begin
breaking the epics up into stories. We have found that the appropriate
final size for a story doesn’t get determined until the story is
actually tasked out. Our epics usually don’t begin and end on sprint
boundaries. We are struggling to find the best way to reassign story
points to the final stories so that we can establish a two week sprint
velocity for a team.
How are others dealing with this problem? Are you able to break the
stories down smaller through the entire backlog? We want to gain
better predictability and we want to be able to make good value/cost
prioritizations. A combination of story points and “product value
points” has really helped us with prioritization, but story points
have yet to give us any advantage in predictability because it is
vague how an epic in the back log will actually get implemented until
it is time to plan it. Are we missing something? What value do other
teams get from story points?
Thanks,
Glenn
George Dinwiddie
On 2/9/12 12:46 PM, Glenn wrote:
> I have some questions around the topic of story points that I would
> like to get some advice on from this group. We have been practicing
> Scrum successfully for many years now. For one reason or another, our
> Development team has struggled to find a meaningful place for story
> points in our process. At some point, the validity of the points
> breaks down because the stories change in size and scope as they move
> through our process.
Yes, I think that will always happen if you try to estimate large chunks
of functionality.
> The majority of our product back log is comprised of epics. We
> currently have assigned story points to all of these. As it comes
> closer to time for a story to get worked on, they go through UX
> research and design, at which point the analysts and developers begin
> breaking the epics up into stories. We have found that the appropriate
> final size for a story doesn’t get determined until the story is
> actually tasked out. Our epics usually don’t begin and end on sprint
> boundaries. We are struggling to find the best way to reassign story
> points to the final stories so that we can establish a two week sprint
> velocity for a team.
What would happen if you just counted those stories?
If you look back at past sprints, has the number of completed stories
been relatively consistent? I've often seen more consistency in the
count than in the sum of estimated story points. I suspect you'll find
that close enough to be able to pull in the appropriate amount of work
for the sprint.
In any event, I would not recommend trying to reconcile the sum of
stories in an epic with the initial estimate of the epic. The time when
that initial estimate had value (if it ever did) has come and gone. By
the time you've split the epic into stories, you have a lot more
information. That information is more valuable going forward. Just use
it and don't worry about the earlier estimate of the epic.
> How are others dealing with this problem? Are you able to break the
> stories down smaller through the entire backlog? We want to gain
> better predictability and we want to be able to make good value/cost
> prioritizations. A combination of story points and “product value
> points” has really helped us with prioritization, but story points
> have yet to give us any advantage in predictability because it is
> vague how an epic in the back log will actually get implemented until
> it is time to plan it. Are we missing something? What value do other
> teams get from story points?
If you want to predict how fast epics might get done in the future, I
would base that on how fast epics have been done in the past. See
http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/ for
one way of doing this.
And if story points aren't giving you any value, I see no problem with
dropping them. The two things people use them for are making projections
and choosing an appropriate amount of work for the next sprint. I should
say, the two USEFUL things--I see them used for a lot of dysfunctional
things, also.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
John Clifford
I'm curious as to why you don't get the appropriate final size, in
terms of story points, for a backlog item until you have completely
tasked out that item, and specifically why your organization believes
that it only can understand the size of an item once it's fully
decomposed into its component tasks. To me, that implies a
misunderstanding of what story points are for.
A key rule of estimation for software projects (whether or not you're
using an Agile approach) is to estimate effort, then derive duration.
Story points are a relative measurement of size, effort, or
complexity. What they are not is a measurement of duration. Of course,
management could care less about effort; they want to know how long
the project is going to take, what it's going to cost, and what they
will get for their money. We do that by estimating EFFORT (the amount
of work we have to do) in story points, estimating (or using
historical data as a source) our VELOCITY (the rate at which we can
implement functionality) expressed as story points/iteration, and then
deriving DURATION by dividing the total amount of scope, in story
points, by our velocity. For instance, if a project's backlog totals
to 520 story points, and we are going to put one team on the project
that can implement functionality at a rate of 26 points per 2-week
sprint, then our duration can be calculated as 20 sprints to
completion (520 points / 26 points per sprint = 20 sprints to
completion)... or 40 calendar weeks (26 points per sprint * 20 two-
week sprints).
'All that sounds great,' I imagine you're saying. 'How do I estimate
story points accurately without decomposing the story into its
component stories?'
You do this by abandoning any attempt to map story points into time
directly, i.e., "the component tasks add up to 180 man-hours, so that
is about a week's worth of work for our team, making this a '13'."
Instead, you choose a story that you've already done, perhaps on a
previous project (or even previously on this project), and it becomes
your reference story, your 'yardstick'. You look at its size, in story
points, e.g., '21 points.' And then, you look at a new story that
needs to be estimated, and you ask the team, "Is this story less
effort, about the same, or more effort than our reference story?"
Let's say the story seems to be about half the effort as the
'yardstick.' Okay, it's a 10.5... but there's no 10.5 in the Fibonacci
series (a useful scale for many reasons), so it has to either be an
'8' or a '13.' Let's make it a '13.' And on to the next new story to
be estimated. Takes a few minutes, is ACCURATE but not precise, and
because we use the Fibonacci series with it's built-in range of 0.6x
to 1.6x the value we are good to go.
"How can that possibly work?" I imagine you're saying. "What if every
estimate is half the actual value?"
It doesn't matter if every estimate is half the value, or twice the
value. What will happen if every backlog item requires twice as much
effort as you originally thought is, your velocity will be half of
what you originally thought; you will be accomplishing 13 points per
sprint instead of 26 points. Your project will take 40 sprints, not 20
sprints. And you will know this very quickly, after a couple of
sprints (a month), so you can alert your project sponsors and product
owner that you won't be able to deliver all of the desired scope in
the original timeframe of 40 calendar weeks, so they can make the
appropriate decisions about cutting scope or slipping the date out
now, instead of near the end of the project when it's crisis time.
"Okay, what if every estimate is either over or under? What if this
story, that I called a '13' is really an '8' and the next story, that
I called a '13' is really a '21'? (BTW I'm glad to see you're liking
the Fibonacci series.... )
Hmmm... 13 + 13 = 26. Interestingly enough, 21 + 8 = 29. A 10%
difference. The effect on the project is that you will see some
variance around the velocity... some sprints you're working on the
'light 13s' and can drag another one in, some sprints you're working
on the 'heavy 13s' and don't get the last one done. The Law of Large
Numbers saves us here; as you estimate a large number of items, the
sum of the errors of your estimates will approach zero. Each
individual story may be off, but the sum of the estimates for all of
the stories in your backlog will be very close to the actual amount of
effort in the backlog. Now, if you have 5 items in your backlog this
doesn't work so well, but if you have several dozen it works very well
indeed. Surprisingly well. Unless you break it by re-estimating
stories in the backlog that have already been estimated. What happens
then is 'Story Point Inflation'... teams will add effort to items as
an attempt to be conservative. Don't re-estimate stories, because
velocity takes care of estimation errors.
The final reason for using story points is, your teams will never be
able to put more than 24 hours per day in. You can increase your
velocity, however, by identifying and removing inefficiencies in your
processes and practices. A good scrum master first works with the team
to identify and eliminate impediments that cause wide variances in
velocity (streamlining - getting the same amount of effort
accomplished with less effort) and then works with the team and the
organization to identify and remove impediments that prevent increases
in velocity (optimization - getting more work accomplished with the
same effort). A mile remains a mile, and I can't run more than 5,280
feet in a mile regardless of how much time I expend, but I can run
more than 5,280 feet, and more than a mile, in 7 minutes... as my
velocity increases because I get better at running due to increased
fitness.
I have coached many teams using the story point approach and it has
worked very well for them, making estimation fairly easy and painless,
and giving teams the ability to measure their velocity and establish a
baseline against which they can improve. It can work for you and your
teams also. In fact, one of the key questions I first ask teams is if
they know what their velocity is... and many teams do not know. I
don't see how anyone can be running Scrum (they may be running a Scrum-
like process perhaps, with some of the benefits) if velocity isn't
measured. Velocity is the heartrate of the team, a single measurement
that tells many things, and tracking velocity and using it to evaluate
process changes is critical to improving, and it's also critical to
project management and tracking.
Let me know if this isn't clear, and I'll be glad to explain more.
- John
John Clifford
Senior Fellow - Agile Practices
Construx Software, Inc.
'Advancing the Art and Science of Software Engineering Best Practices'
http://www.construx.com
Glenn
We have assigned story points to all product backlog items. The vast
majority of these backlog items are more or less epics, for which the
actual implementation is still very vague. We just know we need to do
this general feature and in relationship to other backlog items, it
seems a lot bigger or a little bit smaller. We took the t-shirt size
approach to assigning points.
As the time for one of these epics to be developed nears, we begin UX
research, user testing, and we begin to get a rough idea of what this
feature should behave like. At that point, we begin breaking down the
epic into stories. Thus far, we are not reassigning story points from
the epic to the smaller stories.
Next, by planning day these stories have been broken down even
smaller. Some might be split smaller on planning day to get the
smallest INVEST slices we can get. We value this because it tightens
the cycle time and minimizes work in progress. Again, we have not done
anything with the story points that were assigned at the epic level.
The problem is not that we cannot assign story points until the story
is tasked out. The problem is that we assign story points, and then
the story keeps getting broken down smaller and smaller. If we keep
redistributing the points, they kind of lose validity.
For example.
Epic XYZ is estimated at an XL. (8 points from our Fibonacci scale)
6 months later it goes into research phase and is broken into 3
stories.
Within a month it goes to planning meeting and the final result is 5
stories.
If we wait until the research phase to assign points, we can’t score
the entire backlog and we still have the stories broken down smaller
on planning day. If we try to break the epics down before the research
phase, we are making total random assumptions about what the best
solution would look like.
I think George has an interesting point about counting the sum of
stories. Since we are pushing to get stories to the smallest vertical
slice possible, we are possibly approaching a somewhat standard size –
give or take a day.
Thanks,
Glenn