A Practical Guide: Story Points-Based Estimation
13 January 2014
I imagine you have read many articles about story points-based estimation. Hence, instead of going over how it all works, I will try here to provide a practical guide for how to achieve it.
Before we start, I will assume you are already on a team comprised of at least these members (that is, a Scrum team): product owner, ScrumMaster, developers, and QA. The idea is to get the team to do a comparative analysis of all of the stories for the project. Let's take a look at the following steps:
Identify base stories
It is important to identify one or multiple base or reference stories against which you would do a relative sizing of the backlog. This story is picked from the current product backlog or is a different story that we have done earlier. But what is important is that the understanding of this story is same among everyone on the team. The team should be confident of this base story.
Walk through the requirements of the story
The product owner will provide explanations about what exactly the specific story entails.
Discuss and jot down any details you want to remember when implementing this story
These can be bullet points on the story card or text in the notes section of a tool. This is best done by ScrumMaster, who can add these details as and when discussions are going on.
Sample questions the team should ask (obviously this is a template, and this may vary based on your scenario)
Design: What will we have to learn before we can start work on this story?
Coding: What will be the likely coding effort? Has anyone from the team implemented it before?
Unit testing: Is any special setup required (e.g., mock objects) to unit test this story?
Acceptance testing: How much work is involved in helping the customer automate the acceptance tests for this story?
Integration points: Does the story have any external dependencies?
Expertise: Does anyone have prior experience?
If this story is about the same amount of work as one you have already sized, give it the same number of points. If it is more difficult, give it a proportionally higher value. If this story is similar to another but less work in some way, give it a lower value.
Reach a consensus
Consenting to a proposal of the size of the story as per Definition of Done doesn't necessarily mean it is your choice. Encourage the team to come up with the best estimation that, as a group, everyone accepts.
Validation of estimated story points
Validate that the estimates are internally consistent among stories as you go along. In simple words, the idea is to periodically ensure that all of the 1's are about the same, all of the 2's match. Likewise, the team should agree that a 4-point story is roughly twice as much work as a 2-point story.
This is a rough guide that has worked for me, and I hope it works for you too. However, the key to understand in story point estimates is that it does not matter if your estimates are "correct" or "incorrect" as long as you are consistent.
Current rating: 4 (1 ratings)