When will we get there? It’s not just something you might hear from the back seat of a car on a long road trip. It’s something that a Scrum Team’s stakeholders, customers, managers and many others want to know. When will that thing you are working on be done? How long do I have to wait for you to deliver what I want? Sound familiar?
It’s a reasonable question. To get to an answer that provides meaningful information, your Scrum Team first needs to decide how to estimate. As the Product Owner, you need to take the data from the estimated Product Backlog items (PBIs) and choose how to forecast a delivery date. Today, we’re going to discuss three ways to estimate and in my next post, we’ll talk about forecasting.
Three Ways to Estimate
Estimation is a complementary practice in Scrum, which means that the Scrum Guide doesn’t tell teams how to do it. All the Scrum Guide says on this subject is that the team should size higher ordered Product Backlog items (PBIs) so they can complete them within one Sprint. That’s it. How a team accomplishes this task is entirely up to them.
Most teams use one of three approaches: exact estimation (hours), relative estimation (points), or flow metrics.
Exact Estimation
The first method is the most straightforward for teams newer to Scrum to adopt because teams using traditional project methodologies use it. Exact estimation means estimating in hours or days or some other specifically defined unit of time. It’s just how it sounds. Teams estimate the number of hours or amount of time that it will take to complete each PBI. If the estimate reveals that the team cannot complete a PBI within one Sprint, they must break it down into multiple, smaller PBIs, each of which delivers value to the customer.
For example, imagine that the highest ordered item in the Product Backlog calls for creating a web form with 5,000 fields. The team estimates this work will take 500 hours and they have a one-week Sprint with only five Developers. The team calculates that the 500 hours would take 2.5 sprints (500/40 hours per week/five team members). The team decides to deliver the first 1,000 fields in the first Sprint and the second 1,000 fields in the next, and so on.
While estimating hours may be comfortable for the team, it does have its limitations. Teams using hour estimation tend to get bogged down in exactly how much time a PBI might take to complete, spending more time than necessary to deliver a precise estimate. Hour estimation is also one-dimensional because it does not take into account uncertainty or risk. Furthermore, hour estimation falls short when it comes to the team's ability to learn over time, whether they tend to overestimate or underestimate. Teams don’t learn how much work they can actually do, so estimates do not get better over time. Many of these concerns are addressed in the next estimation method, which involves relative estimation using a points system.
Relative Estimation
Relative estimation differs from hour estimation in that it compares the target PBI to a similar-sized PBI to estimate size instead of establishing an exact estimate. For example, the team might size text changes the same as simple form updates.
The most common way to implement relative estimation is by adopting a point system. Teams can use any type of scale for this purpose, but the most common is the Fibonacci numbering system. Using this system, you create the next number in a sequence by adding the two preceding numbers. For example, if the first number in a Fibonacci series is zero, the next numbers in the sequence are as follows: 1, 2, 3, 5, 8 etc.
Once the team has selected a point system, the next step is to determine which types of PBIs to classify as 1, 2, and so on. There are different exercises to help sort this out, but the team can also just use their judgment to establish the values.
Once the team has set a number system and relative sizes, it’s time to use the point system to size PBIs. Sizing is typically done in a Refinement meeting. Refinement is a complimentary practice where the Scrum team adds detail, sizing and order to items in the Product Backlog. In Refinement, the team can easily determine the type of PBI the new item is most similar to during refinement, and bam, you have an estimate.
As the team delivers PBIs that were sized using relative estimation, they will get a sense of how much work they can complete each Sprint using a measurement called velocity. Velocity is calculated by taking the estimate for each PBI the team finishes in a Sprint and adding the original estimates together. For example, if the team completed five PBIs in a Sprint and the completed PBIs were sized as a 1, 5, 1, 2 and 3, they would add up the points assigned to each PBI to learn they had a velocity of 12 in the previous Sprint. Over time, the team might learn that they typically complete between 8 to 12 PBIs per Sprint. This information is helpful for planning and forecasting purposes. The team can use this calculation to pull in only as much work as they can reasonably deliver in a Sprint. The Product Owner can also use this information to forecast how long it might take the team to deliver 50 - or 100 - points worth of work.
Keep in mind that most Scrum Teams will have a level of variability when it comes to velocity—that’s why it’s called a forecast and not a plan!
Flow Metrics
There is so much emphasis on using the points system that most teams think it is practically the required way to estimate. There is another way — Flow metrics.
Teams using flow metrics look at things such as average lead time to determine how long it will take to deliver their PBIs. They look at things like throughput to determine how much work to pull into a Sprint. Advanced teams might even attempt to size higher-ordered PBIs so that they are close to equal in size. While there are efficiencies gained by such an approach, it is not required. However, it is important for teams using flow metrics to ensure that higher ordered Product Backlog items are sized such that they can be completed within one Sprint. This means that sizing remains important even for teams who are using flow metrics - even if they are not adopting the complimentary practice of making all PBIs roughly equal in size. Teams using flow metrics to plan their work should still discuss size in Refinement to ensure that higher ordered Product Backlog items are sized so that they can be completed within one Sprint.
Below are some common methods teams who use flow metrics use to forecast their work. To learn more about flow metrics or the benefits of limiting work in progress, (WIP) sign up for Rebel Scrum’s Professional Scrum with Kanban class.
Lead time
For a continuous flow process, lead time measures the time it takes from when a request is started/made (such as adding a proposed work item) until that request is completed (closed). For a Sprint or fixed period process, the lead time measures from the time work on a request begins to when the work is completed (i.e., the time from active to closed). This information is especially useful for the Product Owner, who can use this information to build a forecast.
Cycle Time
Cycle Time measures the time it takes to move work through a single process or workflow state. It’s calculated by determining the time between the start of the given process and the start of the subsequent process. In other words, it calculates the amount of time that a work item spends in created state and the amount of time that it spends in active state.
Work in Progress (WIP)
Work in progress (WIP) measures the amount of work or number of work items that the team is actively working on. Limiting WIP is important because when too much work is in progress, it means that team members are likely task-switching, which will likely lower overall productivity.
Throughput
Throughput measures how many items the team produces per unit of time. This information is especially helpful for the Developers, who can use this information to determine how much work to pull into each Sprint at the Sprint Planning event.
Conclusion
Providing stakeholders and customers with a reliable forecast for delivering usable product is central to building trust. To deliver that forecast, Product Owners rely upon teams to estimate completion of items in the Product Backlog. In this discussion, we reviewed three estimation methods. Next time, we will talk about the Product Owners’ role in forecasting.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Introductory class for those new to Scrum
Geared towards Scrum Masters coaching teams
Advanced class for Scrum Masters
For leaders and managers of Agile teams
Professional Scrum Product Owner
For Product Owners
Professional Scrum with Kanban
For anyone interested in learning about implementing Kanban principles within a Scrum team
Both public and private classes are available. To learn more, contact Mary Iqbal.
