Off late, there has been some confusion over the practice of user story estimation at sprint level. The ambiguity is whether to use story points or do an hourly mapping. Let’s explore the ideal practice for user story estimation.
Story points and hours are two very different concepts.
What is a Story Point?
Story points measure the relative size of stories. They take in to account the opinion of the whole team and include a consideration of factors like risk, complexity and external dependencies. It is the use of relative sizing that allows you to generate a velocity. Think of story points as a measure of ‘task’ and velocity as a measure of how much of task can you fit in a sprint.
What happens in hourly estimation?
As soon as you use hours/days in your estimate, you attach an emotional significance to the value. Do you need to do that? And if you do, what if you measure in hours and the team does more or less than the estimated hours? Do you then try and estimate differently to make your estimates more accurate? This approach has been shown to be problematic.
The Right way…
The Scrum approach is to use story points and measure velocity, so that you measure a metric and base your predictions on real data rather than trying to get better at estimating. It is an empirical approach to user story estimation.
How big the story size should be?
It depends on the sprint size, but ideally you would not want a story to last too long. At People10, we rarely have stories lasting more than a few days. If you had a long sprint, say 4 weeks, then you could have bigger stories in. The bigger the story, the harder it is to estimate and it is more difficult to judge progress during a sprint. Better to have smaller stories that you can get ‘done’ and get a good measure of progress.
Deriving effort from size
After sizing, you can use any of the below three methods to derive effort.
- Based on historical data:
Story points are a macroscopic quantity that may be used to make a long range forecast as to likely project completion times based on historical data. The beauty of the story point is that they allow you to compare stories without knowing every single detail of each story. In this way we can say, based on the last half dozen sprints or so, which we expect to complete the project in X amount of sprints with a determinable degree of confidence. - No historical data, a new team:
Pick a random story as a reference and let the team estimate its story points. It’s easy to implement with no complexity, risks or dependencies. Then the team takes the next story and decides if the story deserves more or less story points. You can then re-estimate these stories after the next sprints when the team becomes more familiar with the concept of estimations in Scrum. - No historical data, new team, research type project:
Do a task break down of all features at least for the first few sprints. When you do it for few sprints, you will see that you are able to measure your velocity. It may fluctuate initially, but will definitely stabilize few sprints into the project. Once you build up historical information, you can switch your sizing technique to scenario (1).
