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 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.

Task Estimates

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:

• Powers of 2: 1,2,4,8,16
• Modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, and 100.

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.

Reasons to Estimate the Product Backlog

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:

• How much can you deliver in three months?
• When can a certain set of product backlog items be delivered?

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.

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.