Management wants to know how long it will take to get something done. The problem is that people are terrible at estimating features in hours. Why? Because it is hard work, inaccurate, and not a lot of fun. Scrum teams have a better way – story point estimation.
[featured-image single_newwindow=”false” alt=”Steve Dalton | Poker Planning | Flickr” title=”Steve Dalton | Poker Planning | Flickr”]Steve Dalton | Poker Planning | Flickr[/featured-image]
Hours or duration is complex to estimate on software projects. Teams and individuals are expected to figure out how many hours a particular user story will take to implement – before doing any actual work. It’s not surprising that 60% of software projects fail at this task.
Hours have a different meaning to different people. Developers have varied skillsets, abilities, competencies, domain knowledge, and experiences. Given a diverse development team, a consensus on how many hours a user story will take to finish will be extremely difficult to reach.
For example, let’s take two developers – Senior and Junior. They have been asked to estimate USER STORY X. Senior, who has many years of experience, thinks that USER STORY X will take 5 hours to complete. Junior, who just graduated from college and is working at his first job, and thinks that it will take 10 hours to complete the story. There is no way to reconcile these estimates and reach consensus.
Even if the hours could be reconciled, the meaning behind the hour estimates are unclear. Is that 5 hour estimate expressed in ideal time or elapsed time? In other words, is that 5 hours of work assuming no interruptions, distractions, and other commitments? OR is that 5 hour estimate really 20 hours in duration because the work was spread over 3 days due to meetings, disruptions, or other life events?
Instead, scrum teams use story points – a unit of measure for the size of a user story. The actual values and units are not as important as the value of the stories relative to one another. A story that is a 10 should be twice the size of a story that is a 5. The estimate is also all inclusive. Everything that is need to get the user story completed is considered in the process.
In our case, Senior and Junior can decide that USER STORY X represents 1 story point. They could then look at other user stories on the product backlog and decide the story point value of the remaining user stories based on their relative size to USER STORY X.
This abstraction removes the complexity of estimating in hours and simplifies the estimate to a relative sizing exercise. Mike Cohn put it best in his excellent book Agile Estimation and Planning: “A story-point estimate is an amalgamation [consolidation] of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherit in it, and so on.”
Hours based estimating is popular, but it is also more complex. It is also frequently wrong. There are many variables that are out of your control that you end up having to factor in (more guessing) or ignore (bad guessing).
Estimating is waste. Customers do not pay for estimates. You can’t claim ROI from an estimate. Scrum teams do not deliver estimates at the end of every sprint, they deliver working software. Estimates have no intrinsic value. So why invest a lot of time on them?
Since scrum teams know that they are going to be “wrong” when estimating, they use story point estimation to quickly and inexpensively size their user stories. As they inspect and adapt their work during and after each sprint, they can revisit their estimates and adjust as needed.