Scrum Guide | 23. Story Points and Estimation in Scrum

In today’s article, we cover the topic of Estimation and Story Points in Scrum. Creating estimates in Scrum helps to predict the complexity and time required to complete tasks. By analyzing the past, the entire Scrum Team collectively forecasts what the future holds.

Therefore, the more experienced the Scrum Team is, the more accurate their estimates are. The team also collaborates on establishing the estimated time to complete the tasks during Sprint Planning, keeping in mind, that it’s not a final commitment but a prediction. Its accuracy depends on numerous variables that constantly undergo unforeseeable changes and unexpected circumstances. Fortunately, Scrum methodology includes techniques and tools to facilitate some degree of certainty, and today we’ll discuss them in detail so you can understand and apply them straight away!

Story Points and Estimation in Scrum – table of contents:

1. Introduction
2. The Importance of Story Points in Scrum
3. Relative estimation techniques
4. Summary

Introduction

At each Sprint Planning, the Product Owner presents new User Stories to the team. The Product Owner selects them from the Product Backlog for implementation in the next Sprint. Then Scrum Team members jointly estimate the workload necessary to complete this new batch of duties. This kind of assignment is an estimation, requirements estimation.

It would seem that the simplest way is to define the time needed to complete the task in hours or days. However, practice and research conducted since the 1940s prove otherwise. Humans are unable to accurately estimate the time required to complete even very well-defined tasks. Besides, the number of hours needed to complete a task depends on who is doing the task, and what has – or has not – been done before. This is why Scrum typically uses units called Story Points.

The Importance of Story Points in Scrum

Each Development Team puts into practice the value of a Story Point by drawing from experience and the size of individual tasks, i.e., following the principle of empiricism. Most often, during Sprint Planning, the Scrum Master selects one or more samples of completed User Stories, which serve as a reference point for determining the value of the User Stories to develop.

That’s why you can’t assign values in Story Points without the context. For example, if the first task is assigned a value of 10, subsequent tasks will be evaluated against it as either greater or lesser. In this way, within a Scrum Team project, all the tasks in the Product Backlog are related to each other. This means that similar tasks performed by one Development Team will receive a similar number of points.

Story Points are relative units. This means that:

1. The Story Point value relates only to the tasks performed by a particular Scrum Team. Story Points describe the speed of completion of the tasks of one team. In other words, a User Story estimated at 10 Story Points by Team A, can get 50 by Team B. This is because, as we mentioned, their value is relatively calculated to other tasks performed by that team, and their experience with similar tasks.
2. The value of Story Points completed in one Sprint cannot be the basis for comparing the performance of two Scrum Teams. In order to avoid mistakes in managing Scrum projects, it is important to remember that the Speed of a Development Team expressed in Story Points done in one Sprint cannot be used to compare the performance of two Teams. This is because they could do the same work in parallel Sprints, which one Team estimated at 10 and the other at 50 Story Points.

It should also not be forgotten that the estimation contains many unknown elements and is made on the basis of incomplete data. For this reason, the predictions of even a very experienced Scrum Team can sometimes be very different from the real effort needed to complete a User Story.

Relative estimation techniques

What are the most effective estimation techniques in Scrum? There is no one-size-fits-all method that works for each team.

Among the estimation techniques within agile methodologies, the most common are:

• Planning Poker. This most popular relative method takes a card game to calculate the amount of work to complete a task. It’s detailed rules and process we’ll cover in a separate article.
• Team Estimation Game. This one involves assigning execution of User Stories in a given Sprint with appropriate numerical values selected from the Fibonacci sequence. We have also devoted a separate article for it too.

Scrum, on the other hand, rejects the classic Absolute Estimation way of the traditional project management methodology. The way it estimates tasks is by defining in advance the person-months, duration, and cost of the whole project. This is a long process, difficult to implement, and requires the participation of experts who tend to establish the rationale and the code of conduct, but take no action who will not necessarily perform the tasks whose value they estimated. In other words, it is not only tedious but also highly inefficient.

Story Points and Estimation- Summary

Estimation is a very important skill that characterizes all mature Scrum Teams. Estimating the amount of time and effort required to complete individual tasks became the main focus of many relative estimation techniques such as Planning Poker or Team Estimation Game.

User Stories with Story Points is yet another efficient measuring technique we described, hopefully providing our readers with some handy tools. However, it is important to keep in mind that their figures relate only to the particular tasks performed by Scrum Team. Therefore, the number of Story Points cannot become the foundation for comparing the speed of different Development Teams.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.