Andreas Tennert

When software developers estimate a task that is in the backlog, then they estimate the complexity of this task. Complexity can mean many things. For instance, it can be uncertainty about some parts of the task, risks and/or simply the amount of the actual work. A popular way to measure this complexity is to assign Fibonacci numbers to the tasks. An easy task might be a one or a two. A hard task might be a 13 or a 21. The unit of measurement is usually called Story Points (SP).

What does it mean when a task gets assigned three SP and what does it mean when a task gets assigned 13 SP? When thinking about this question, it's quickly getting clear that not only the assigned number is relevant, but also the scale itself. When a team estimates a task to be of a certain complexity, then the meaning of this complexity is knowlegde of the team. This knowlegde builds over a period of time during which the team members get a common understanding of the scale. Additionally, a task that is now estimated with 13 SP might be estimated with 5 SP a few months later, because the team knows more about the software, tools, frameworks, ... . As a result, one team can estimate a task to be of two SP and another team estimates the same task to be of five SP and both are right, because the meaning of the scale is relevant as well. This difference is totally fine. The important part is that the team members get a feeling for their work and the software that they are building. Grooming and estimating as a team is about exchanging knowlegde about the work that needs to be done, the risks, the uncertainties, ... . This understanding is inherent in the team. The conclusion is that a person, who had no interaction with the team, has no idea of what a number of SP on a task means in terms of the complexity of the task or what kinds of complexity are part of the estimation.

After estimating a task, the task has a number. What can be done with this number? First and foremost, it can be used by the developer team in a review to compare it with the actual work that went into the task and reevaluate their understanding of the software, the risks, ... and their understanding of the complexity of the tasks. A new team needs some time to get a common understanding of complexity. When team members are added to or taken from a team, this teams understanding of the complexity might change. If that happens, the scale will be applied differently and the estimations change. I dare to say that the understanding of a scale for estimations usually stays stable in a stable team after a phase of familiarization. When this stabalization happens, a Product Owner (PO) can also use the SP values to create a rough estimation on the burn down of the tasks.

What shouldn't be done with estimations? Estimations should not be a base for financial calculations. They are rough estimations on the different aspects of task complexity and a tool for teams to grow. Using the SP to calculate the pay for the developers and the PO and the Scrum Master removes the original purpose. Btw., how do you put the work of a PO and a Scrum Master into the SP? Every sprint would be about having at least a minimum amount of SP to cover the expenses. When the SP go up it's also dangerous, because the person paying the money might get suspicious on why he suddenly needs to pay more. He/She might be happy that a team gets more work done but how could that be possible in a world where SP are directly converted into work time and money? Additionally, the person transferring the SP into money has no idea of the teams scale. He/She would need to enforce his/her scale on the team in order to do those calculations.

The team would also loose it's estimation history. When looking back to the past sprints, a team that estimates with abstract values will have ups and downs in the sprints in terms of SP. This history is telling a story that the team can review upon and learn from. There should be questions like: "Why are there so many/few SP in this sprint?" The answers are usually about tasks that turned out to be harder or easier then expected and why. That is valuable information which is easily lost in an environment where a certain amount of SP needs to be reached. The story is removed when the SP get "fixed" to "correct" the estimations according to the work done.

Finally, when using the estimations for monetary purposes, the estimations need to be exact in terms of timing. Wait ... Why did someone invent estimations on abstract scales again? Oh yes, because people are bad at exact estimations.