The effort of backlog items in Scrum should be estimated so that a Scrum team knows how many of them it can implement in the next Sprint. The developers estimate the effort in the estimation meeting. This can be done with different methods. In this article I will show you how to estimate with points and you will learn one of the most popular estimation methods in agile projects, Planning Poker and one of the most efficient methods, Magic Estimation. Take the next step and deepen your knowledge!
How to Estimate with Points
In the article How to Estimate the Effort for Product Backlog Items in Scrum you learned how to conduct an estimation meeting. The most important activity in it, is of course, to estimate the effort of each backlog item, only then you know how many of them you can implement in the next sprint.
In contrast to traditional estimation methods, agile methods do not estimate the effort of a user story in “line of codes”, but mostly use points (story points).
Working with points is very easy. First, a scale of points is defined with which an estimate is to be made. A non-linear scale, which corresponds approximately to a Fibonacci function, has proven itself in this context. This means that the larger the estimate, the greater the distance between the estimates. Here you see what this scale looks like:
1,2,3 . 5 . . 8 . . . 13 . . . . . .20 . . . . . . . . . . . . 40 . . . . . . . . . . . . . 100
If you estimate requirements with points, you always estimate the effort relative to another requirement. This means that at the beginning you will estimate a small requirement from the Product Backlog, which you know how to implement. Then, you estimate another requirement in relation to the first estimate. Once you have estimated more than two requirements, compare the new requirements with existing estimates for further estimates. This ensures that the estimates are relative to each other.
Especially if you value requirements as “very large” (e.g., “40”), it may make sense to go into more detail and break them down into separate user stories to get a more accurate estimate.
The quality of the estimates will of course improve if the Developers understand the requirements well and know the necessary work steps for the implementation.
The Problem With Story Points
Estimating stories and features in Scrum using story points has several potential disadvantages. Following a few examples:
- Story points are inherently subjective and can vary significantly between different teams or even within the same team over time. This can make it difficult to maintain consistency and comparability in estimates.
- Stakeholders who are not familiar with story points may misinterpret their meaning.
- While story points can help with short-term planning and sprint management, they are less effective for long-term planning and forecasting.
- Teams might spend too much effort trying to achieve precise estimates rather than focusing on the actual work.
- For new teams or projects without historical data, establishing a baseline for story points can be challenging. This initial lack of calibration can result in inaccurate estimates and planning difficulties.
- Story points often focus on functional requirements, potentially neglecting non-functional aspects such as performance, scalability, or security. These important factors might be underrepresented in the estimation process.
Story points are a useful tool for agile teams. Being aware of these disadvantages can help teams mitigate their impact and make more informed decisions about their estimation practices.
Make Story Points Measurable
The Story estimates consider factors like work, complexity, risk, and uncertainty. However, the raw value of Story Points is relative and does not directly translate into time or monetary values. This can pose challenges when requiring meaningful estimates for budgeting and scheduling purposes. Story Points also don’t provide a measure of physical percent complete since they have no physical unit of measure. Is a Story Point Story worth an hour’s effort, 30 minutes effort, or three days of effort?
For Story Points to be more useful in business, they need to be calibrated to cardinal units of measure such as dollars and hours, which are used by those funding the project. This calibration helps in converting Story Points into a format that decision-makers can understand and use effectively. The difficulty lies in ensuring this calibration remains consistent across different teams and projects since interpretations of Story Points can vary.
In the next sections, I will show you two estimation methods with which you can efficiently carry out the estimation process with Story Points.
Planning Poker
Planning Poker® was first used and named by James Grenning in 2002 and later made popular by Mike Cohn in the book Agile Estimating and Planning. Planning Poker® is a fun way to conduct the Estimation Meeting efficiently.
At the beginning, each participant gets a stack of Planning Poker® cards with values from 0 to 100. The values correspond to the non-linear scale of a Fibonacci series of numbers that you already know. Then, the Product Owner presents a user story from the Product Backlog. The team will clarify any ambiguities with the Product Owner. Then, the team discusses the steps that are necessary to implement the user story. Then, each team member selects the card from their stack of Planning Poker® cards that best suits the effort of the User Story and places it face-down on the table.
At the same time, all team members turn their cards around. If the card values are very different, the team members who are furthest apart explain why they have chosen their value. After that, an estimate is made again after the same procedure. Estimates will often converge in the second round. If this is not the case, repeat the process until the team has agreed on an estimate. It rarely takes more than three rounds to reach the goal.
If the Scrum Team doesn’t know about Planning Poker® yet, the process will still be quite slow. But as soon as a few rounds are played, it gets faster. If you want to make planning poker efficient, use a 2-minute hourglass timer for each round of poker.
The moderator takes notes during the Planning Poker® session that can be helpful when programming and testing the user story (Cohn, 2017).
Magic Estimation
If you need to estimate 50 or 100 user stories, Planning Poker is too slow. That’s why more and more Scrum Teams are using *Magic Estimation”, a method Boris Gloger adopted and refined from Lowell Lindstrom.
For Magic Estimation you will need a set of Planning Poker® cards, the floor or a large table and the user stories from the Product Backlog prepared by the Product Owner. The cards with the user stories should be written as large as possible so that they can be read by larger groups even from a greater distance.
The Product Owner places the Planning Poker cards in a row of numbers on the table or the floor, separated by distances corresponding to the proportions:
1,2,3 . 5 . . 8 . . . 13 . . . . . .20 . . . . . . . . . . . . 40 . . . . . . . . . . . . . 100
There is one important rule in Magic Estimation: Do not speak during the performance!
How to Perform Magic Estimation
- The Product Owner distributes the backlog item cards evenly to the team.
- Each team member reads their backlog items, estimates the effort based on the Planning Poker® numbers, and places the cards near the corresponding numbers on the ground.
- When a team member has distributed their cards onto the row of numbers, they read the cards laid out by other participants. The team member changes the position of a card when they think the card belongs in another position. All participants do this in parallel and without discussing it with the others.
- The Product Owner observes what is happening. When the Product Owner sees that a card is frequently moved, they will know there are differences of opinion.
- If a team member does not know what a card means, they put it on the number “100”.
- The game is over when no cards move or there are only “moved” cards left. The game ends also when the participants slowly turn away and become visibly bored.
- At the end, the team members write the final estimated values on the backlog item cards.
- Cards that have been moved to the end or cards on which there is no agreement are taken by the Product Owner. These can be discussed with the team and then placed and moved again or the value is determined with Planning Poker®.
When Using Magic Estimation and Planning Poker®
Many teams will have a planning poker session or magic estimation for the first time in the estimation meeting shortly after an initial Product Backlog has been created. The purpose of this session is to provide initial estimates that are useful for sizing the project and release planning.
Effort estimation with Planning Poker or Magic Estimation are regularly carried out during the entire project duration. This is because new backlog items are constantly being added or existing ones are constantly changing. The best time for this is the Estimation Meeting just before the end of the Sprint.
Effort estimation with distributed teams is somewhat more complex. There are some free online tools, for example for Planning Poker®. You will find these on: https://www.planningpoker.com/
Here You Can Find More Knowledge
Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!
Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!
