Story Point Estimation

I guess that most of the discussions around any part of Scrum that I participated in so far were related to estimating. Should we estimate in hours or in those ominous story points, and if we choose the latter, what does a story point describe? Is it the sheer duration of the story? Then why not estimate it in hours and save all the trouble of converting story points to hours? — Or does it describe the complexity? Then how can we make use of the estimations for our release planning? E.g. a complex formula may be implemented quickly (because it can be taken from a book) while implementing a routine thing may take a significant amount of time (because it requires lots of manual work).

Usually, story points are described as a measure of the “size” of a story, where “size” is said to include a number of factors like complexity, duration, risk, and so on.
And usually, no further description is given on how to measure these factors. It is implicitly assumed that people know this already. In this article, I want to produce more insight and intuition on how to estimate in Story Points.

How can we Estimate the Size of a Story?

I think that it is of utmost importance that any team learns to take into consideration that ít is dangerous and wrong to restrict their estimations to just the time it takes to type the code into the editor. Instead, the estimations need to reflect the possible duration of a number of aspects:

  • Complexity: It takes time to think about possible solutions, to do some research, to decide which way to go, to implement some spikes, and so on.
  • Risk: What can go wrong with the story, how much uncertainty is in the solution we are likely to favor? How much experience does the team have with this solution? How much extra time should be added to cover these issues
  • Implementation: How long does it take to implement the desired solution? How much time do the automated tests take? How many tests do we need, and what kinds of tests? Do we need manual testing as well? Do we need to refactor the code? Maybe we even need larger code restructurings or architecture discussions?
  • Deployment: What is required for deployment? Do we have an automated build system in place or does it involve manual work? How long does it take to start the application and to inspect the new feature manually? What if we encounter problems?
  • Interdependencies: Is the task dependent on results that are not available yet? Is there any coordination required before the work can start? How long does it take until feedback is being provided, e.g. because the Product Owner is not always available?

The team should become sensitive with respect to these issues, and the team should become aware that simply suggesting a number of hours (while at the same time assuming that this number has anything to do with reality) does not do justice to the spectrum of factors illustrated above.

The sum of all of these aspects is what is usually referred to as the “size” of the story.

The time that needs to be considered until a story is called “done” can only be given as an order of magnitude of this size. And that is exactly what a Story Point is about: It is just an order of magnitude for the size of a given story. Not more, and also not less.

8 thoughts on “Story Point Estimation

  1. Pingback: Tweets that mention Story Point Estimation « Pair Blog about OO-Programming --

  2. Good post here. I would suggest that there would also be (included in your list) a relative estimate or baseline that developers can use when estimating their stories.

    I’ve found that this works very well when you have all your developers understand relative size of a story.
    This relative size also (usually) includes complexity, inter-dependencies, and implementation requirements.

    • Your point is of course valid — as soon as a team is actually doing an estimation, it is important to have some estimation techniques at hand. Using a reference story as baseline is a useful approach.
      My article, on the other hand, tries to establish an understanding of which factors are relevant and should be considered in estimates — no matter which estimation technique is being applied. In other words, the article tries to focus on the “what” of the estimation process and deliberately leaves out the “how”.

  3. Story estimation is one issue, another is the estimation of the whole project. I can’t see (yet) how the relative size (of stories) could be a solution for that challenge. At the end of the day (more often before ;-) the customer wants to see the big picture he’s going to pay for.

    • When writing the article, I had estimations in agile projects in mind. When I read your comment related to traditional fixed price projects, I realized that the aspects mentioned above are important in traditional projects as well, and they need to be considered and integrated in the estimations. So, no matter whether the estimations are given in story points or in hours or days, the effort it takes to produce the software covers much more than the coding time.

  4. Hi Nicole,

    estimating is a black art and there are ongoing discussions about it – be it in the Scrum/agile community or in the community of traditional project management. I like your short but there are even more factors that have an impact whether the story can be rated as DONE DONE. Most dangerous are factors that are not controlled by the developers but are coming from outside. Thats the reason to check if a story is READY READY to develop (something which is very often skipped / not possible).

    However my experience shows me that in the end all estimates are always are translated to hours/days but still it creates value (confidence) if you estimate in abstract values in a first step.

    In the comments of one of my articles in I highlight an additional important aspect for the German speaking Scrum community:

    “[…] Übersetzungsfehler: „Compexity“ wird nicht nur mit „Komplexität“ übersetzt sondern eben auch mit „Aufwand“ ;-) […]”

    Guess some of the discussions come from the one sided translation of complexity to German.


  5. Nice article. For me story points are about splitting the time it takes to do something (which is, let’s face it, what we would like to know if possible) into 2 main groups of components. Those things that can reasonably be estimated, and those that can only be measured after something is done. Story points represent the former, and the teams velocity represent the latter.

    The main reason we can’t estimate how long things will take, and need can only estimate an abstract component is because at the time things are estimated, usually during backlog grooming or the first part of the planning meeting, so many things are unknown, for example what the solution will be, and who will do it.

    I find this dichotomy between what is estimable in points, and the velocity that is measured afterwards, corresponds roughly to the dichotomy between problem and solution. Teams have more luck understanding the difference between points and hours, when they realise that only the problem, or what needs to be done, can be estimated in points. How long it actually takes depends heavily on how it is solved, and encapsulated in the velocity metric.

    Points describe problems.
    Velocity describes how teams solve problems.

  6. Pingback: [Agile Guide] - Estimating User Stories in Agile | Agile ScoutAgile Scout

Leave a Reply


You are commenting using your account. Log Out / Change )

Twitter picture


Facebook photo


Google+ photo


Connecting to %s