As an agile trainer I often get asked why story points are better than hours. Admittedly story points are more abstract on first glance compared to hours. Everyone is used to hours, the are a more tangible concept, i.e. something that we can all readily identify with. However once you have started to use story points and ironed out the ‘paradigm shift’ issues you will find them a more reliable measure of progress throughout your project. Here I will summarize why and provide you links to the experts like Mike Cohn and Jeff Sutherland who can give you the detail.
1. My Hours aren’t Your Hours
When we estimate in hours, and this is usually done individually. We can therefore make the mistake of assuming a similar level of skill exists. This is rarely the case but when we do this it can mean that when we come to doing the work that the lateness of tasks ripples down the schedule (and doesn’t get made back). So we rely on the rough accuracy of story points as our guide and use the reality of project execution to re-calibrate to that reality as we go forward. Traditional Wide-band Delphi helps mitigate against individual bias but still missing the point of relative estimates in a group setting such as done in Planning Poker (incorporates Wide-band Delphi in a faster paced collaborative environment).
2. It’s about the Effort
Mike Cohn gives a wonderful example. Consider licking one thousand stamps and brain surgery. Both could take around the same amount of time, however which is more complex? It’s about the effort rather than complexity. Take this further and relate back to item 1. Different people will take a different amount of time – how can we base our estimates on the a perfect case scenario. This is just wishful thinking. Even if we have the right person for the job how will they feel for the day, week or month?
3. It’s about Collaboration
The way we do agile estimation is a group exercise through planning poker or affinity estimation. These methods encourage group behaviour that have desirable effects such as catching out overly optimistic or overly pessimistic estimates. Groups transfer knowledge more readily and this is done in this fast paced and least wasteful environment. It’s well documented the benefits of groups estimating versus individuals – see the Wisdom of Crowds (James Surowiecki) and book The Wisdom of Crowds.
4. Points do not decay
My ability to write Fortran code was a lot better 20+ years ago than it is today. My estimate from back then would be a lot sounder than one I gave you today. Today’s estimate would be a lot larger to factor in start up time and relearning. Over time if I kept doing Fortran that estimate would decay and become better. The effort would still remain the same. (Please note – I’m not advocating going back to Fortran). You can rely on points estimates lasting a lot longer then hours estimates.
5. Points are a Pure Measure of Size
When we talk in units of time like hours we can easily fall back into bad habits such as asking how long. This has dangerous side effects that can skew velocity readings making them next to useless. We use velocity (how much we complete) with story points to drive duration. We need to ensure we keep each in relative accuracy to get reliable duration. Incorrect application will result in the oft quoted ‘Agile doesn’t work’ – often without looking at the root reasons why it has failed and making the required corrections.
6. Points are a Unit of Production – Hours are not
Jeff Sutherland makes the apt point that you cannot measure progress in hours completed. Hours are a cost and they more often than not represent the cost of the non-value adding activities. Story Points because they are delivered with a rigorous definition of done are a unit of value to be relied upon for the explicit delivery of customer value i.e. the working software, the working solution, the completed portion of the construction project. If we were to compare this to a traditional project we could have completed 2000 hours of a 4000 hour project. We’d be 50% complete on this reading but only have delivered the requirements specification. In my experience this is often when the actual budget has been exhausted. Furthermore it has been my experience and the experience of many others that similar or less budgets can deliver working solutions without a request for further budget.
7. Hours should only be used when we have precise information
In traditional project management, hours estimates are done when we have the least amount of information. The well known Cone of Uncertainty shows that in the earliest stages of a project we can be out by a factor of 4. This is where points estimates work better. Because they are a relative measure of size we can compare against other similarly sized items and get an accurate but not precise reading on the effort required to deliver a feature. This is done with a small amount of efforts (minutes). We know that spending more time has a diminishing effect. Hours should be used only when we have the most amount of information available to us. In iterative frameworks like Scrum this is at the sprint planning stage whereby we can satisfy a definition of ready for a story before we proceed to development. An aside, a framework like Kanban says that estimates are optional – that is a subject for another blog post though. A twitter debate is raging over this – look the the hashtag #NoEstimates.
8. Jeff Sutherland notes that agile delivery results in much more successful project outcomes. One of the factors (amongst others) is the reality imposed by story points estimating (with constant re-planning along the release cycle). Venture capitalists who have seen both traditional and agile methods for estimating realize that velocity is key to success and not detailed hours based work down breakdown structure Gantt charts which you can throw away after you’ve created them (as Mary Poppendieck routinely calls out)
9. Humans are just no good at estimating based on hours. Humans are great at comparing the relative sizes of things. A great game you can play to illustrate this is the fruit salad exercise whereby a group given some already sized fruits (groups through to pineapple) are asked to estimate using story points more fruit – comparing the new fruit to the already estimated fruit.
So I recommend using Story Points in your estimating and using hours when you know the most amount of information. Hopefully I’ve given you enough of a start to find out more. Mike Cohn has a great book called Agile Estimating and Planning. This is the one source for the extra detail you will need.