If story points are about time, what is truly the benefit of using them?

Question

Quoting the known Mike Cohn:

The primary reason for estimating product backlog items is so that predictions can be made about how much functionality can be delivered by what date. If we want to estimate what can be delivered by when, we’re talking about time. We need to estimate time. More specifically, we need to estimate effort, which is essentially the person-days (or hours) required to do something.

What is the benefit then? If the team equally estimates all the tasks in MDs, instead of SPs, they will be able to do the exact prediction of what can be delivered by a certain date.

Answer 1

If story points are about time...

Story points aren't about time. They are about the amount of effort required to complete a task.

The idea of story points is that, regardless of who does the work (their experience, availability etc), the amount of effort needed doesn't change. The time taken may change, but the effort doesn't. So a scrum team aims to determine its velocity over the course of a set of sprints. That velocity is the number of story points it can typically handle. It's an average figure that allows for variations in team composition, absences, tasks proving more complex than thought etc. So it aims to offer a more accurate estimate of what can be achieved each sprint.

If you estimate in terms of time, then you have to factor in the fact that John is less experienced than others, so he'll contribute less and Mary is on holiday for three days so will contribute less etc. This makes calculating how many hours of work can be achieved in a sprint hard. Story points aim to hide all that detail away behind abstract estimates.

The problems with story points are twofold. People find it hard enough to estimate in hours, let alone in story points, so they'll often estimate it in hours then translate that using some arbitrary conversion into story points. That defeats the whole point of story points of course. Secondly, and far more importantly, people will still estimate the story points wrongly more often than they get it right. Estimates are guesses after all. Educated guesses, but still guesses. So the estimate will still be wrong on many occasions.

What is the benefit then? If the team equally estimates all the tasks in MDs, instead of SPs, they will be able to do the exact prediction of what can be delivered by a certain date.

"Exact prediction". Really? In the entire history of software development, I very much doubt there's been a single team anywhere that has performed an exact prediction of how long a non-trivial piece of work will take, other than by pure luck. They played the estimate lottery and guessed the numbers correctly. Estimating is guessing; there is no exact science to it. Story points can help with estimating, but they aren't a silver bullet. The only way to know precisely how long a piece of work will take is to wait until it's finished and then calculate the time taken. But that's not really estimating then...

Answer 2

There are a few things to consider. First, quoting people from books can be problematic. As their understanding changes their books don't. Mike Cohn actually talked about this exact topic in a keynote a few years ago discussing how his opinions about estimation have really changed over the years but people still quote his old opinions from books.

To the spirit of the question though, a more recent blog post from Cohn talks about correlation to time. An example he uses is running. If you run a 5k in 30 minutes consistently, the next 5k you run will probably take you around 30 minutes. Now, if you are sick or the weather is bad or you are recovering from an injury or the route is different, that number can vary wildly. Therefor, with relative estimation, a team that regularly completes, say, 25 story points in a 2 week sprint will probably complete around 25 points the next sprint and will probably complete 100 story points in 4 or 5 sprints. Since exact estimation in hours has a long track record of being wildly inaccurate (usually by far more than a week or two) the relative reliability of this approach is considered by most teams to be a step up in value.

Others who promote relative estimation would also point out the value of estimation (as opposed to estimates). The act of estimation often drives our important conversation to create a clearer understanding of the work. In fact, there is a growing number of teams who simply throw out the estimates after this stage - they find this is the primary value and that the estimates themselves often cause more damage than good.

Answer 3

What is the benefit then? If the team equally estimates all the tasks in MDs, instead of SPs, they will be able to do the exact prediction of what can be delivered by a certain date.

I think it's already be noted but bears repeating: 'exact prediction' does not happen.

That aside there's one big reason this is done: people are very bad at estimating how long something will take in terms of absolute time. People tend to be reasonably good at looking at a deliverable and compare it to something they've already done. For example, a home builder can look at a plan for a house and determine that it should take roughly as long to build as houses of similar complexity and size.

Story points are a way of categorizing deliverables into groups that are roughly the same level of effort. The idea is then that the PM can look at completed deliverables and use the time they actually took to extrapolate to a reasonable prediction of how long the new deliverable will take to deliver. This is why the definition of 'done' is really crucial in agile methodologies.

The actual times that deliverables take for each story point classification should fall into something like a normal curve. This means that estimates can be statistical in nature e.g. you can say that there's a 98% chance it will be done in less than 2 weeks given past performance. You can even use these to plug in to things like PERT and make predictions about a large body of work, if that's needed or desired.

The key here is to understand how different this is from asking someone to tell you how long something will take. As I noted up front, people are pretty bad at this. Mostly they will pad the estimate to avoid being under, then end taking all that time plus some.

Answer 4

The main benefit of story points is that it moves the time estimation responsibility from the dev team to the project manager.

The dev team give an estimate of task complexity and the PM converts that to time based on their own calculations of previous velocity, number of team members off sick/on holiday blocking tasks etc etc.

This nicely divides the estimation task into two components which can be better managed. The dev team doesn't have to think about resource planning and the PM doesn't have to think about coding complexity