Why estimate with story points rather than time (days, ideal days, hours etc.)?
Estimating in real days does not integrate “the other” things you have to do like answering the phone, taking care of emails, meetings, interruptions etc. To compensate for this we include a focus factor normally around 60-80%. It is difficult to set and it needs updating. The focus factor is multiplied to the “ideal days” to compensate for the extra activities we do.
With story points we do not need to apply the focus factor. It is built into the system automatically. So how do we use story points?
- Let the team choose the smallest story, from the product backlog. This story is assigned the value of 3 points.
- Estimate the rest of the product backlog using the above story as reference: Take the next story. Let the team estimate how much bigger it is than the reference story. If it takes 4 times longer it gets 3 * 4 = 12 points. Do this for all stories.
Because we use a ref. story we gain another advantaged over estimating in ideal days. When you estimate in time, two people will not always give the same estimate simply because they have different experience levels. Using a ref. story eliminate most of the differences because if a junior developer is slower on the ref. story he is also likely to be slower on the other stories.
What about stories that cannot easily be estimated i.e. bugs?
It’s clear that some stories can be difficult even impossible to estimate i.e. bugs. We do need to estimate everything. Sometimes it helps to break stories down in smaller pieces but if you end up with a story the team cannot estimate you have two options:
- Give a qualified guess. This is better than nothing and it gives an indication to the PO.
- If all else fails you can set the estimation at the maximum amount of time the PO is willing to spend on the feature and go from there.
How do we convert story points to time?
After each sprint you count how the story points for the stories which have been finished completely. Unfinished stories do not count, not even partially and not even if the story is 99% completed. Unfinished work has no business value and is therefore not counted.
If your sprint is 1 week then you now know how many points the team can finish per week. This is the velocity of the team, story points per sprint. The velocity will stabilize after 2-4 sprints.
How do we select stories for the first sprint?
Since we do not know how many points the team can do in advance we have to guess. Ask the team how many they are Ok with. It’s better to select too few than too many. If the team finishes before time they can always grab the next story from the top of the PBL.
Conclusion:
Using story points has two significant advantages over ideal days:
- We do not need to determine the focus factor for the team.
- We get similar estimates from different people.
Story points simply give us better and more precise estimates.
Recent Comments