Chapter 7: Estimation and Velocity

This chapter describes the concepts of estimation and velocity. I begin with an overview of the important roles that estimation and velocity play in agile planning. I then discuss the various items that we estimate and when and how we estimate them. The bulk of the chapter focuses on how to estimate product backlog items, including how to choose a unit of measure and use Planning Poker. Next I move on to the concept of velocity and how using a velocity range is essential for planning. I discuss how new teams can forecast velocity in the absence of historical data. I conclude with ways we can influence velocity and how velocity can be misused.

OVERVIEW

To answer the typical product development planning questions how many, by when and at what cost, Scrum teams estimate the size of what they are building and measure their velocity (rate at which they can get work done). Using that information, they then derive the likely product development duration and the corresponding cost by dividing the estimated size of a set of features by the team's velocity. This chapter looks more closely at estimation and velocity.

WHAT AND WHEN WE ESTIMATE

Most organizations make estimates for planning purposes at three different levels of detail, depending on whether they are working in the portfolio backlog, the product backlog, or the sprint backlog.

Portfolio Backlog Estimates

A portfolio backlog is a prioritized list of all the products (or projects) that need to be built. Because backlog items at this level tend to be less detailed, portfolio backlogs are typically estimated using rough, relative size estimates such as T-shirt sizes (small, medium, large, xlarge, and so on).

Product Backlog Estimates

Once a product has been approved for development, its product backlog items become more detailed. As these PBIs rise in priority, their estimates become more fine grained. Product backlog estimates are typically expressed as story points or ideal days. This kind of estimation typically occurs in product backlog grooming meetings, the first of which usually coincides with initial release planning.

Task Estimates

Tasks in the sprint backlog are typically sized in ideal hours. So if the team estimates that a task will take five ideal hours to complete, that doesn't mean it will take five elapsed hours. It might take one person several days or it might take several people working together less than half a day. Task estimates are covered in more detail in Chapter 19.

PBI ESTIMATION CONCEPTS

Though all three levels are detail are important, the remainder of this chapter focuses on estimation at the product backlog level, beginning with a discussion of several important concepts that Scrum teams use when estimating PBIs.

Estimate as a Team

In Scrum, we follow a simple rule: The people who will do the work (the development team) collectively provide the estimates. Because everyone on the development team sees the story from a different perspective, it's essential that all members of the development team participate during estimation.

The product owner and ScrumMaster do not do any hands-on estimation. Instead, the product owner describes each PBI and answers any clarifying questions while the ScrumMaster coaches and facilitates.

Estimates Are Not Commitments

Estimates are not commitments, and if you want realistic estimates, rather than artificially inflated ones, it is important not to treat them as such. 

Accuracy versus Precision

Estimates should be accurate without being overly precise. The more precise we try to make our estimates, the less accurate they'll actually be. Instead, invest just enough effort to get a good-enough, roughly right estimate. Trying to be too precise only creates waste.

Relative Size Estimation

Estimate PBIs using relative sizes, not absolute sizes. In other words, determine how large each item is relative to others. People are much more accurate at gauging relative measures (e.g., halfway there or a third full) than they are at absolute measures (e.g., 14 feet or 2.75 ounces).

PBI Estimation Units

Story Points

Story points measure the bigness or magnitude of a PBI from the development team's perspective. Points combine factors like complexity and physical size into one relative size measure, with the goal of being able to compare stories and say things like, “If this feature is a 2, the one over there is about a 5.” 

Ideal Days

An alternative approach for measuring PBIs is to use idea days—the number of effort-days or person-days needed to complete a story. Ideal time is not the same as elapsed time. An American football game would be measured as 60 minutes in ideal time (4, 15-minute quarters), but the elapsed time is closer to 3.5 to 4 hours. The main drawback of ideal time is that it can be misinterpreted as elapsed time, which creates confusion and frustration.

Planning Poker

Planning Poker is a consensus-based technique for estimating the effort associated with PBIs. It was first described by James Grenning in 2002 and popularized by Mike Cohn in 2004. 

Estimation Scale

Before playing Planning Poker, the team must first decide which scale or sequence of numbers it will use for assigning estimates. It should then create, or purchase, a set of cards that is printed with these numbers, in sufficient quantities that everyone on the development team has a card for each possible choice on the scale.

Because the goal is to be accurate rather than precise, teams should not use all of the numbers but instead favor a scale with more numbers at the small end and fewer numbers at the large end. Commonly used scales include a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, and 100) and one based on powers of 2 (2, 4, 8, 16, 32). By using a relative scale, teams can group items of similar effort together in bins by assigning them the same number.

How to Play

Play begins with the product owner reading or describing the PBI and answering any clarifying questions. The team then discusses the PBI. When the team is ready, each member privately chooses the card from his stack that best corresponds to the level of effort for that PBI. Once everyone has chosen a card, all the team members show their chosen card at the same time. If all of the cards match, the team writes down the estimate and moves on. If all the cards do not match, the team discusses the PBI further. In this discussion, the conversation focuses on the rationale of the highest estimator and the rationale of the lowest estimator. Once the discussion has died down, the team members once again select and play their estimate cards. This process is repeated until all of the estimates match. The ScrumMaster coaches the team during this process, looking for ways to improve collaboration and ensuring that all team members are engaged.

Planning Poker does not use averages or any numbers not existing in the chosen scale. The goal is not to compromise but instead to reach consensus. The discussions the team members have to reach this consensus are crucial for reaching a shared understanding of each PBI and improve the accuracy of the estimates.

Benefits

Planning Poker brings together the diverse team of people who will do the work and allows them to reach consensus on an accurate estimate that is frequently much better than any one individual could produce. The majority of the value of Planning Poker is the discussion it fosters. I'm much more concerned about the team learning about the PBIs than I am in what size they ultimately chose for the PBIs.

What Is Velocity?

Velocity is the amount of work completed each sprint, typically measured by adding up the sizes of the completed product backlog items. Velocity measures output (the size of what was delivered), not outcome (the value of what was delivered). Velocity is used primarily for release planning and as an internal team measure to determine whether process improvements made by the team are helping.

Calculate a Velocity Range

For planning purposes, velocity is most useful when expressed as a range (10-15 vs 12). Using a range allows teams to be accurate without being overly precise. 

Forecasting Velocity

One of the benefits of having long-lived teams is that they will acquire useful historical data, including their actual velocity data. But sometimes teams are newly formed and have no historical data. In those cases, they'll need to forecast a velocity range. One way to do this is to have the team plan two sprints and use the two estimated velocities (estimates of how much work the team thinks it can accomplish in each of the two sprints) as the first velocity range (the two estimates will likely be different). Then, as soon as the team has performed a few sprints and recorded its actual velocity, the team should discard any forecasts and begin to use the actual numbers. 

Affecting Velocity

Although a team that is aggressively trying to improve itself is likely to see an increase in its velocity over time, its velocity will eventually plateau. That is both acceptable and expected. At that point, the team can still improve, but might need to use new tools, incorporate new training, or tweak team composition in order to positively affect velocity. Keep in mind that at first these changes might actually cause velocity to dip, as the team gets used to a new way of working.

Misusing Velocity

Velocity should not be used as a performance metric to judge team productivity. Instead, velocity should assist teams with performing accurate planning and with improving internally. Any other uses will likely promote the wrong behavior.

Closing

This chapter discusses ways to estimate size and measure and use velocity. The next chapter deals with technical debt.