4

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.

  • Points lead to velocity, which is a predictor of how much a team can deliver over a time period. Don't equate points to time. Only after a few iterations can you start to predict how much a team can deliver over an iteration because there will be data to base a prediction on. – Jon Raynor Jan 22 at 14:53
3

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...

  • Some authors (including Mike Cohn himself) argue story points are exactly about time, with some influence of complexity and unknown. – John V Jan 22 at 13:30
  • The problem with less experienced people does not magically disappear with story points. If the team agrees something is 5 SPs and the less experienced one gets it (the one who might have had raised 10 SP card during the poker), the problem is still there. In addition, all companies I have been to used to SP for stories, but then planned subtasks with hours... – John V Jan 22 at 13:33
  • Also, I do agree story points are about effort, which Mike says himself, but effort translates into time (the very first sentences): mountaingoatsoftware.com/blog/… – John V Jan 22 at 13:38
3

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.

  • This can be done in an environment which is more flexible, such as a product development. In fixed time, fixed price, fixed scope projects, the estimates, at least high level, are even in the contract, they are basis for the price.. – John V Jan 22 at 14:10
  • I think the question here is if relative estimation gives you a more accurate guess than absolute estimation. Once teams get proficient at relative estimation, they often find that the forecasts are more useful than the absolute estimations are. – Daniel Jan 22 at 15:26
  • @daniel that is very interesting about the Mike Cohn keynote address. Would you by any chance remember the name or know how I can find it? People I work with are so emotionally invested in using ideal days that they like to quote Agile Estimating and Planning to say "even Mike Cohn thinks it's valid to use them" (even though in the book he says he prefers story points) – stifin Sep 25 at 13:47
  • 1
    I couldn't find that keynote, but he delivered the same keynote at Mile High Agile which I found at (youtube.com/watch?v=VlQ2ls_hm8o). You want to watch from about 4:30 to 14:15 (really, all of it is good, but that refers to this experience with estimation) – Daniel Sep 25 at 21:16
1

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.

0

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

  • I have never heard that a PM would do that. But anyway, where is the benefit here? If the DEV team provide estimate already in hours, the conversion step disappear and the estimates will be more accurate. Especially in fixed time, price, scope environment this has no value. – John V Jan 22 at 10:50
  • If I estimate 10h for some coding task, but then take 3 days off work. how long will the task take? – Ewan Jan 22 at 10:52
  • Still 10h, the resource capacity in the PM will show that. I mean, you simply know the deadline and available hours.. – John V Jan 22 at 10:53
  • but its not complete for 4 days right. So what was the benefit of using hours? – Ewan Jan 22 at 10:58
  • If you estimate a task as being 2 SPs and then take 3 days off work, it is the same. How is this different? – John V Jan 22 at 10:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.