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


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

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.

Estimation and Story Points in Scrum

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.

Scrum Guide | 23. Story Points and Estimation in Scrum caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing