Problems with story point estimates
Story point estimates have become standard in agile and Scrum. There are a number of problems with these estimates, however. This article will explain what they are, and what the alternatives are.
Where do story points come from?
The history of story points is a little unclear. Ron Jeffries’ name often comes up. He claims he either “invented them or was there when they were invented”.
One thing is certain, however: they are not part of Scrum (despite what many people believe). The phrase “story point” does not appear once in the Scrum guide. The guide does mention estimation of the backlog, though nothing is said about what sort of estimates or how they are done.
They were popularised in Mike Cohn’s influential book “Agile Estimating and Planning” from 2005. Mike Cohn is probably the most known author and blogger in Scrum, so his practices have become very widespread.
So let’s discuss the problems with story points.
People don’t understand them
I’ve lost count of the number of frustrating discussions and arguments I’ve had about story point estimates. Talking about basketballs and tennis balls, writing up Fibonacci sequences, explaining why they aren’t a unit of time.
Relative sizing isn’t a very strange or complex topic, but people don’t seem to like it when estimating work. This applies to both the people producing the estimates (who are usually developers) and people asking about the estimates (who are usually managers). They often end up getting turned into hours, turned into random numbers, or turned into something else altogether.
They are easily misused
Since they are frequently misunderstood, story points are easily misused. Managers think they are a measurement of the amount of work or productivity or effectiveness of a team. This reflects a complete misunderstanding of the meaning and purpose of agile metrics.
This can lead to terrible situations where managers are comparing teams to one another by using their velocity as some sort of “efficiency benchmark”.
They encourage focus on the wrong things
Story points estimates can encourage a number of bad behaviours.
They can encourage teams to “game the system” by continually increasing their estimates. This seems to increase velocity, but is fake and makes a mockery of the process.
They can encourage teams to “rush” work through the system, marking stories as done that are not quite done, or have outstanding defects or technical debt. They can encourage teams to focus on numbers and “output”, instead of value and outcomes.
They are annoying to do
Story point estimation is not fun. The main method used is Planning Poker. This is a lot less fun than it sounds, believe me. I would rather claw my eyes out with forks than sit through a one or two hour planning poker session. Fortunately there are some alternatives to planning poker, but they are still annoying and not a valuable use of time.
They are not necessary
People have been brainwashed into believing that story points are a core part of Scrum (they’re not part of Scrum at all), that they are a great way of estimating and planning work (they’re not), and that there are no alternatives (there are).
The truth is, they are not necessary at all. Teams can find other ways, to focus on throughput and value, rather than points and estimation.
What are the alternatives?
There are a number of alternatives to story point estimates.
Time estimates
This option seems the simplest: replace story points with time estimates. This will avoid the confusion and arguments about story points, but leaves most of the other problems there. Teams will still have to estimate, and they will still be focused on outputs instead of value.
High-level estimates
Another option is to do high-level estimates only. The team will just estimate the size of higher level items such as features or epics and use larger units of time such as weeks or sprints. This solves some of the problems with velocity being misused as a metric and is generally quicker and less painful than story point estimation and planning poker.
However, this can send a dangerous message to managers, and teams can frequently be held to those estimates as if they were a concrete plan or commitment.
No Estimates
There is also a more radical alternative: No Estimates. This movement was launched by Woody Zuil and has been popularised by Vasco Duarte and others. There are a few approaches to this, but a popular one is to simply count stories. That is, to use story throughput (number of stories) as a metric. If your stories are all small and roughly of equal size, you should be able to simply count them and forecast using story throughput. This can encourage the team to reduce waste and prioritise value rather than size or estimations.
Conclusion
I hope you can now see some of the problems with story point estimation, and some alternatives. Have you tried these alternatives? What results did you get? Please let me know in the comments!
