The purpose of the Sprint is to deliver a done increment of valuable, usable product. In order to get there, it is important that higher ordered Product Backlog items are sized so that they are small enough to be completed within a single Sprint. The purpose of estimation in Scrum is to size higher ordered Product Backlog items so they can be completed within a single Sprint.
Sprint Success: The Ultimate Goal
The heart of Scrum lies in its Sprint, a time-boxed event during which a Scrum Team collaboratively works to complete a set of Product Backlog items. The primary objective of estimation in Scrum is to size these items so they are small enough to be completed within a Sprint. This is crucial for ensuring that teams can consistently deliver value in a predictable manner. (See our recent article, Developing in One Sprint and Testing in the Next Is Not Scrum.)
The Drawbacks of Hours-Based Estimation
For traditional approaches such as Waterfall, hours-based estimation has been a go-to method for estimating and planning work. However, it comes with several drawbacks, especially when dealing with complex work. One significant issue is that people tend to over or under-estimate tasks, often influenced by their personality or biases. This subjectivity can lead to inaccurate estimations, affecting Sprint planning and ultimately the team's ability to meet commitments.
Furthermore, teams who estimate in hours can fall into the trap of being judged based on how accurate their estimation is, rather than being judged based on the quality or value of the Product that is delivered. We should never confuse estimation as an end in itself. Our purpose is to deliver valuable increments of functionality and to predict when future commitments will be met. Estimation is a tool, and we need to remember that the purpose of estimation is to provide a forecast. There are better ways to forecast value delivery than hour estimation.
Relative Estimation and Flow Metrics
In response to the limitations of hours-based estimation, Scrum Teams are turning to alternative methods such as relative estimation (using points). Alternatively, teams are increasingly using flow metrics as a simpler and often more accurate way to forecast value delivery.
What is relative estimation?
Relative estimation is a technique used to estimate the size, complexity, and effort required for each Product Backlog item. To use relative estimation, the Scrum Team first selects a point system. Common point systems include Fibonacci or a simple scale from 1 to five. (See our recent article How to create a point system for estimating in Scrum.
Once the team has selected a point system, they create an agreement which describes which type of items to classify as a 1, 2, and so on. It is possible for the team just to use its judgment, documenting that information in their team agreements.
Then, when the team needs to estimate new work, they simply compare the new work to similar work done in the past, and assign the appropriate number.
The benefits of relative estimation are that over time, as the team delivers PBIs estimated this way, they can get a sense of how much work they can actually deliver each Sprint using a calculation called velocity. You calculate velocity by taking the estimate for each PBI you delivered in a Sprint and adding them up.
For example, if the team completed five PBIs in a Sprint sized as a 1, 5, 1, 2 and 3, then by adding up the points assigned to each Done item, the team can learn that their velocity in the previous Sprint was 12.
What are ‘Flow Metrics’
Flow metrics is an increasingly popular way for Agile teams to forecast work. Rather than sizing work using hours or relative estimation, the Scrum Team simply asks the question: is this Product Backlog item small enough to be completed within one Sprint. If yes, then they are done.
Over time, the Scrum Team will get a sense of how many Product Backlog items that they can complete within a Sprint. They don’t need to be equally sized either. As long as the Scrum Team has a relatively normal distribution of work - that is to say that some items are small, and some are large, but they generally have the same types of work in the Product Backlog - then flow metrics can be a very accurate way to predict figure value delivery.
Benefits of relative estimation and flow metrics
Both relative estimation and flow metrics have gained in popularity in recent years for several compelling reasons:
Learning Opportunity: Both relative estimation and flow metrics provide a valuable learning opportunity for the team. Instead of obsessing over the accuracy of individual estimations, these methods encourage teams to focus on consistency. Over time, teams develop a better understanding of their capacity and velocity, allowing them to make more reliable commitments in Sprint planning.
Irrelevance of Over or Underestimation: In relative estimation or flow metrics, whether a team tends to over estimate or underestimate becomes irrelevant. What matters is the team's ability to deliver a consistent amount of work within each Sprint. Teams adapt to their own estimation tendencies, making it easier to predict their capacity accurately.
Value Delivery Focus: These methods align with the Scrum principle of maximizing value delivery. Instead of getting bogged down in minutiae, Scrum Teams can prioritize and complete the most valuable backlog items within a Sprint.
Benefits for the Product Owner
Effective estimation methods are not only valuable for the Scrum Team but also for the Product Owner. By consistently estimating work using points or flow metrics, the Product Owner can gather data over time about how many points or what number of Product Backlog items the team typically delivers per Sprint. This historical data can be leveraged to create forecasts, helping the Product Owner understand the team's progress towards their goals and make informed decisions about product development.
Conclusion
The purpose of estimation is to size Product Backlog items so that they can be completed within a Sprint. While hours-based estimation has been a traditional approach, it often leads to inaccuracies and distracts from the primary goal of delivering value. Relative estimation and flow metrics have emerged as more effective alternatives, focusing on consistency, learning, and value delivery. These methods not only benefit the Scrum Team but also empower the Product Owner to make data-driven decisions and better plan for the future. In the end, Scrum is about delivering value, and the right estimation method can make all the difference in achieving that goal.
Save the date for Scrum Day 2024 in Madison, Wisconsin. Scrum Day is an opportunity to network with thought leaders and Scrum practitioners.