Story Point Estimation

Now to be found here.


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

Fill in your details below or click an icon to log in: Logo

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

Google+ photo

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

Twitter picture

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

Facebook photo

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


Connecting to %s