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.
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.
Reasons to Estimate the Sprint Backlog
Now let’s look at why teams should also estimate the sprint backlog. The are two reasons to estimate the sprint backlog. First is that it helps the team determine how much work to bring into the sprint.
By splitting product backlog items into small, discrete tasks and then roughly estimating them during sprint planning, the team is better able to assess the workload. This increases the likelihood of the team finishing all they say they will.
Second, identifying tasks and estimating them during sprint planning helps team members better coordinate their work. For example, if sprint backlog items are not estimated, a team might not notice a critical path through the work or that the designer will be the busiest during the coming iteration.
