When working with user stories, story points, and SCRUM, it is common that a smaller story takes longer to complete than a larger story. While this is reminder that story points reflect complexity, not effort, it is often taken as a signal that the team needs to go through a process of re-estimating user stories. Normal distribution tells us that over a large enough sample, all three point stories will take about the same time to complete. A team’s desire to re-estimate stories based on a few stories deviating from the norm is a mistake.
Not All User Stories are Created Equal
If you rolled a pair of dice a million times, the majority would add up to seven. If you graphed the data, you would see a bell curve shape. User stories are no different. Over a large sample, you start to see the same bell curve shape in those stories.
Some three point stories might take two hours to complete while others take twelve; but most take seven. At the same time, some of your five point stories will take ten hours to complete and some twenty four; but most take eighteen. Consider the overlap in the following diagram:
Some of the three point stories and some of the five point stories will take the same amount of time to finish. But this should not be mistaken for a need to re-estimate user stories. Sometimes a three point story will take as long to complete as a five point story. That’s normal.
Commitment Driven Planning
A commitment-driven approach is an alternative way to plan an iteration. Commitment-driven iteration planning involves many of the same steps as velocity-driven iteration planning. However, rather than creating an iteration plan that uses the yesterday’s weather idea to determine how many story points or ideal days should be planned into the current iteration, the team is asked to add stories to the iteration one by one until they can commit to completing no more.
So what happens when a three point story is tasked out and comes to ten hours, and a five point story is tasked out and comes to nine? Often times the first inclination of the team is to inflate the three point story. Especially interesting is that almost no one suggests to shrink the estimate of the five point story. Again, we should expect that some three point stories will take the same amount of time to complete as some five point stories, but in the end this will even out.
Velocity is The Great Equalizer
Again from Mike Cohn’s Agile Estimating and Planning
What’s happened here is that velocity is the great equalizer. Because the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. We cannot simply roll a die and assign that number as the estimate to a feature. However, as long as we are consistent with our estimates, measuring velocity over the first few iterations will allow us to hone in on a reliable schedule.
As the team complete more and more sprints, developers will come across three point stories that are a little larger than average and five point stories that are a little smaller than average. Between our bell curve distributions and velocity acting as the great equalizer, over time, the bumps in the estimations will smooth out and the desire to spend time re-estimating user stories will go away.