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