Why Five and Five are not Always Equal

Whenever I introduce Scrum teams to Planning Poker, one simple question arises. Why are some problems estimated with the same Story Point value, although they seem to have completely different characteristics? This article explains why it is not meaningful to compare tasks with the same Story Point value to each other, and how Story Points group problems into orders of magnitude.

Why #noestimates is not an Option

First of all, let’s have a look why it is not an option to not estimate your upcoming tasks and work packages if you are working in a Scrum team. In case you are part of a Kanban team it is perfectly fine to do #noestimates. Kanban is intended to be used in an environment where all tasks are more or less equally sized. Hence, no estimation is required. Scrum is supposed to be used in complex environments, where the sizes of tasks can vary significantly. That’s why the Scrum Guide tells us something about the information that is supposed to be added to a Product Backlog item during the refinement.

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.

Additionally, how would you want to perform a Sprint Planning, without knowing how many work you are supposed / allowed to plan in the upcoming Sprint? As Scrum relies on empirical process control theory, we rely on our observations and knowledge of past events and the current context we are operating in. This means, that we do not make assumptions when making decisions, but rely on facts, even if we don’t like them.

Hence, we constantly measure the capacity of the team and use the results as input for our Sprint Planning. Furthermore, we estimate the size of the upcoming work packages, as this will allow an informed Sprint Planning. Here, we use the teams capacity as an upper bound for the amount of work that can be planned.

Story Points as an Estimation Technqiue

This leads us to the question, which estimation technique is a good choice for use in Scrum teams. Here, Story Points have several built-in features that make them a really decent fit for use in Scrum environments.

Story Points do not only decouple the discussion and estimation of tasks from the unspeakable folklore of effort estimations. Furthermore, Story Points allow teams to include the aspects of risk and uncertainty into their estimations.

However, one question always arises when introducing Planning Poker and Story Points to a new team. Why are some tasks estimated with the same Story Point value, even if if they appear to be so different?

Handling Risks and Uncertainties

One of the core concepts of estimating with Story Points is the classification of problems into orders of magnitude, which is called the problems complexity. As opposed to classical effort estimations, we do not try to estimate the correct size of a problem in planning poker. Here, we try to estimate its magnitude. Hence, a Product Backlog item which is estimated with 13 points belongs to a group of problems with sizes ranging from 10.5 points to 16.5 points. This complexity value includes risk, and uncertainty, and the ranges get bigger along with the size of the estimated problems.

story points cover a certain range of complexity
Fig. 1 - Ranges of Complexity Covered by Story Point Values

On the other hand, teams have to be aware of that fact. Even if we group Product Backlog items according to their magnitudes, the work items of a specific group can still have very different sizes. So, it is not meaningful to compare work items of a group regarding their actual implementation efforts afterwards. It’s still only an estimation, and the estimation is just a representation of the problems magnitude, and not its effort.

Final Thoughts

Although it may seem comfortable to establish a #noestimates environment, it is not an option for Scrum teams. Story Points have evolved as the leading estimation tool in agile teams. Nonetheless, the question arises why some stories are estimated with the same value, as they seem to have very different characteristics. The Story Points values are not accurate measures of a problems size. They represent orders of magnitude that group problems of approximately identical effort, risk and uncertainty together. This uncertainty grows along with the problems’ size, and thus the range which is covered by a single value grows as well. This leads to the effect that the size of problems within a single group can differ. Regarding to Story Points and the related problems sizes, five and five are not always equal.

Back to blog

From theory to practice? Attend agile training courses at AgileSkills!

1 of 4
  • Lead Time und Cycle Time in Kanban Systemen

    Lead Time and Cycle Time in Kanban Systems

    When discussing Kanban systems, the terms "lead time" and "cycle time" often come up. However, different people use these terms differently and sometimes they are even used synonymously. This article...

    Lead Time and Cycle Time in Kanban Systems

    When discussing Kanban systems, the terms "lead time" and "cycle time" often come up. However, different people use these terms differently and sometimes they are even used synonymously. This article...

  • Throughput und Delivery Rate in Kanban Systemen

    Throughput and Delivery Rate in Kanban Systems

    Although the terms throughput and delivery rate are often used interchangeably, there are subtle differences between them. This article explains the exact difference between throughput and delivery rate in the...

    Throughput and Delivery Rate in Kanban Systems

    Although the terms throughput and delivery rate are often used interchangeably, there are subtle differences between them. This article explains the exact difference between throughput and delivery rate in the...

  • Ein kurzer Leitfaden über Objectives und Key Results

    A Beginners Guide to Objectives and Key Results

    Objectives and Key Results (OKRs) is a goal-setting framework that helps organisations set clear, measurable goals. This article shows the definition of OKRs as well as good examples that could...

    A Beginners Guide to Objectives and Key Results

    Objectives and Key Results (OKRs) is a goal-setting framework that helps organisations set clear, measurable goals. This article shows the definition of OKRs as well as good examples that could...

  • A Beginners Guide to Kanban Metrics

    A Beginners Guide to Kanban Tools

    Kanban boards are used by teams to map their workflow and current tasks. Unfortunately, many teams lack the knowledge and ability to assess the performance of their workflow. How fast...

    A Beginners Guide to Kanban Tools

    Kanban boards are used by teams to map their workflow and current tasks. Unfortunately, many teams lack the knowledge and ability to assess the performance of their workflow. How fast...

1 of 4
Dr.-Ing. Stefan Döbrich

Questions and Answers

Do you have unanswered questions about agility?

Do you still have questions about the article, agile methods or problems with implementing agility in practice?

Write to me and we'll arrange an initial meeting! We'll get started together. I promise!

Get in Touch Now