Software Development Methodologies
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.
© 2019 Digcode.com. All rights reserved.