do you Estimate
So how do you estimate requirements; it doesn’t matter if they are
written as User Stories or features or even use cases. The problem is not the
mechanics of the process, rather it’s the actual estimate.
How many of you have sat in a Estimation meeting or Sprint Planning
meeting where you have been asked to play Planning Poker and estimate the story
points of a User Story?
The whole team needs to participate – after all it’s a team sport, so
you can’t get out of it.
The first question asked by the newbies is - What’s a Story Point
worth, is it a days’ worth of effort?
I have heard lots of answers to this question from a simple
”” Yes you can think of it
that way “” – Oops ??
“”It’s the complexity of
the story”” – What does that mean ?!?!
So you all go over the story / feature and ask questions so that you
understand it better. Actually, if you’re like me, you start to build a
solution in your mind about how you are going to solve the story. Then you
convert it into effort.
Is this the right way to estimate? Actually, I don’t think so.
Story Points are not viewed in Person Days. They do relate back to
complexity and using the team’s velocity you are able to measure how that
relates to how many story points in a sprint.
So in the end it does relate back to effort.
But initially it all starts with complexity.
So what can help you estimate the complexity??
You can use the Affinity Grouping. This is a fast way to estimate
multiple stories / features. Simply group stories / features together that are
roughly the same size.
1. Draw up columns for the relative sizes - small, medium, large,
extra-large. The basic Tee Shirt sizes.
2. Select the first story and discuss as a team if it’s a small, medium,
3. Place into the correct column.
For all the other stories, its now just a
relative comparison. Is it the same, smaller, larger? If necessary, just add a
new column – Extra Small, Extra Extra Large.
You can then convert from Tee Shirt size to Story Points – Small = 1;
Medium = 5; 2XL = 34 …
Of course, the trick is determining the complexity for each story or feature.
It’s a given that the smaller the size of the story / feature the easier it is
to estimate the complexity. It’s a given that you would be more accurate
estimating building a window compared to building a house.
So story / feature splitting is very useful when you know the
story is too large and you are unsure of the size. After all what is the
difference between a 2XL and a 3XL feature. Actually, the difference can be
Remember not to split by technology stack. Ask as you split the story,
how are we going to show that the story is complete.
There are also other factors you can include when
determining the complexity:
The level of Customization required – level of new work required
· Is the feature Out of the Box – limited or next to no effort required to do the work.
· Modification of existing functionality – Something similar exists and you just need to change it. It’s a matter
of how much it needs to be changed – a small amount or a large amount.
· Custom Capability – You
need to build this feature from the ground up. Its brand new. Since its new its
going to be harder and there maybe some unknowns.
Feature Categorization –
the type of feature being built
- Basic Feature - Is
this a basic feature that has been done by everyone – it doesn’t mean that
its simple or easy to build, but all the risks have probably been worked
out and you’re not learning as you go. This should be easy to estimate.
- Performance Capability – Is this feature / story cutting edge and
relatively new? Again, there is some risk, but it’s not completely strange
and the risk is manageable. The estimate will need some contingency as its
not cookie cutter work.
- Excitement Capability – Is the feature / story brand new and
hopefully never thought of before? Its something that you will need to put
effort into, to design and get correct.
The actual Complexity
· Obvious – this is well known, and you just need to follow a well-worn path or best
· Complicated – This is still known and it’s a matter of following good practice and
analyse thoroughly. Just need to determine some things or bad things will
· Complex – There are lots of unknowns which need careful analysis and planning.
It’s really all new and will need some probing (spikes) to work out the
· Chaos – Absolutely new and unknown. All you can do is organize a series of spikes or experiments to learn what seems to work. This is almost unable to be
estimated and should be really be broken up into the Spikes & experiments
which are time limited.
All these approaches help in determining the complexity score – story
points for the features and stories. The more effort spent on the estimation
improves not only the estimate, but also the teams understanding of what is
being asked of them.
It’s well known that each team will come up with slightly different
estimates, but as this is a team sport, the estimates usually don’t vary too
much especially if you have a consistent approach.
Of course, their estimates on what they can achieve will get more
accurate as they compare what can actually be done against what they thought
could be done. This is experience and an experienced team will estimate better
that a team which is just starting off.
This is the empirical approach and as they say – practice make