Estimation and Velocity in Scrum
Throughout the development life of a product, we need to use different units to estimate portfolio backlog, product backlog, and sprint backlog.
Portfolio Backlog Item Estimates
Although the portfolio backlog is not formally a part of Scrum, many organizations maintain one that contains a prioritized list of all of the products (or projects) that need to be built. To properly prioritize a portfolio backlog item we need to know the approximate cost of each item. As I discussed in Chapter 5, we typically won’t have a complete, detailed set of requirements at the time when this cost number is initially requested, so we can’t use the standard technique of estimating each individual, detailed requirement and then summing those estimates to get an aggregate estimate of the total cost. Instead, to estimate portfolio backlog items, many organizations choose to use rough, relative size estimates like T-shirt sizes (such as small, medium, large, extralarge, and so on).
Product Backlog Estimates
Once a product or project is approved and we start adding more detail to its product backlog items. When PBIs have risen in priority and been groomed to include more detail, most teams prefer to put numeric size estimates on them, using either story points or ideal days.
At the most detailed level we have the tasks that reside in the sprint backlog. Tasks are sized in ideal hours.
A story point is an abstract measure of effort required to implement a user story. It is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.
In most cases a story point uses one of the following scales for sizing:
In order to do that each team would have to find a baseline story. It does not necessarily to be the smallest one, but the one that everyone within the team can resonate with. Once determined, sizing of all the user stories should be initiated by comparing them against the baseline.
Velocity is the amount of work completed each sprint. It is measured by adding the sizes of the PBIs that are completed by the end of the sprint. A PBI is either done or it’s not done. The product owner doesn’t get any value from undone items, so velocity does not include the size numbers of partially completed PBIs.
Velocity is used for two important purposes. First, it is an essential concept for Scrum planning. For release-level planning, we divide the size of the release by the team’s average velocity to calculate the number of sprints necessary to complete the release. Additionally, at sprint planning, a team’s velocity is used as one input to help determine its capacity to commit to work during the upcoming sprint.
For planning purposes, velocity is most useful when expressed as a range, such as “The team is typically able to complete between 25 and 30 points each sprint.” Using a range allows us to be accurate without being overly precise.
There are three main reasons to estimate a product backlog. First, it allows a team and its product owner to make longer term predictions about how much can be delivered by when. It allows teams to answers questions like:
Second, it aides product owners in making prioritization decisions. Priorities should be set based on the expected benefits and costs of the product backlog items. A product backlog item estimated at 3 story points, days, or whatever units you use, is typically a higher priority than it would be if it were estimated at 100.
To say this isn’t the case would mean that you always order the best wine on the wine list or drive the best car manufactured regardless of price. Chateau Mouton-Rothschild 1945, anyone?
Most of us, including product owners on agile projects, cannot afford to make decisions that way. In prioritizing work, we consider the cost of developing product backlog items. For most items, the estimate of the effort involved is the biggest component of the cost.
A third reason to estimate items on the product backlog is that team members become more knowledgeable about the item by thinking about it enough to estimate it. This means there will be fewer surprises when the feature is being developed.
© 2020 Digcode.com. All rights reserved.