It is very common for agile teams, especially Scrum teams, to estimate both their product backlog and sprint backlogs. In this article, I’ll address:
- Why estimating both the product backlog and sprint backlog can be useful even though it seems redundant
- Why teams should estimate the two backlogs in different units
- When teams should estimate
- Whether all teams should estimate
If you’re new to agile or need a quick reminder about what the product and sprint backlogs are, you can watch these two videos on the product backlog and sprint backlog.
Why You Should Estimate both the Product Backlog and Sprint Backlog
It’s useful to estimate both the product backlog and the sprint backlog because the estimates are used for different reasons.
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.
Why Estimate In Different Units
Because the estimates on a Scrum teams two different backlogs serve different purposes, they should be made in different units.
For product backlog items, in particular, it is vital that the team can estimate quickly.
To see why, suppose a boss asks the team to estimate when forty product backlog items in the form of user stories can be delivered.
This could be an entirely valid request. Perhaps the boss wants to know whether to hire additional team members if the project will take too long. Or perhaps the boss only wants to start the project if it can be reasonably expected by a specific date.
If the team were to answer the boss by splitting each user story into tasks, as is commonly done in sprint planning, and estimating each of those, the time spent estimating would be huge.
If we assume an average of 15 minutes discussion and estimating per user story (as is commonly needed during sprint planning), estimating 40 user stories would take 600 minutes or 10 hours of whole-team effort.
If the team can instead use higher-level but equally accurate estimates on the product backlog items themselves, those estimates can usually be created much more quickly. I advise teams to target three to four minutes on average per product backlog item. In this case, estimating 40 user stories would take no more than 160 minutes, or about 2-½ hours.
The best way to do this is for a team to estimate its product backlog items in story points and its sprint backlog tasks in hours.
This works well because story points are a more abstract measure that individuals with different strengths can agree on. Just as you and I can agree on the length of the measure “one foot,” even though our individual feet are most likely different lengths, so can agile team members of different skills agree that this user story will take twice as long to do as that user story.
Story points don’t work, though, at the sprint level. During sprint planning, remember the goal is for a team to determine how much work to bring into the sprint. That’s hard with abstract units like story points. It’s far easier with hours.
Estimating in hours is feasible on a sprint backlog because sprints typically contain fewer items than the entire product backlog, which means it won’t take as long. Plus, a typical sprint task will be performed by one person. And in many cases, it’s clear which person will do it. These factors make it feasible to estimate a sprint backlog in hours.
When to Estimate the Product Backlog
It’s clear that sprint backlog items should be estimated as part of a sprint planning meeting when the sprint backlog is created. But when should a team estimate its product backlog items?
I recommend estimating product backlog items at two different times. First, estimate a day or two after holding a story-writing workshop.
This is a meeting I recommend product owners conduct for their teams on a (roughly) quarterly basis. The goal is to identify the user stories needed to achieve some larger-than-a-sprint initiative. Identifying those product backlog items could take 2-4 hours (per quarter). Estimating them should then take an hour or two more.
The second time a team should estimate product backlog items is once per sprint, if new product backlog items have been added since the previous sprint. This can happen any time but it should be relatively late in the sprint to minimize the chance of new stories coming in afterwards. Most commonly this is done during a team’s product backlog refinement meeting or immediately following a daily scrum when everyone is already interrupted and present.
Why Not Estimate Product Backlog Items During Sprint Planning?
It may seem like a good idea to estimate product backlog items right at the start of the sprint planning meeting. However, there are two big problems with this.
First, it’s too late for the product owner to consider the estimate when prioritizing.
Remember that one of the reasons why teams estimate their product backlog items at all is so that the product owner can prioritize. If the product owner isn’t given estimates until the start of sprint planning, it’s not realistic to assume the product owner will fully consider those when prioritizing.
Second, teams that estimate product backlog items at the start of their sprint planning meetings tend to spend much longer estimating.
I suspect this is because team members are about to perform more detailed sprint planning. With their minds on that, the need for more detail often creeps into the effort to estimate the product backlog, making it take longer than my target of 3-4 minutes per item.
For these reasons, try to estimate any new product backlog items that need to be estimated outside of sprint planning and also late enough in the sprint that most (if not all) new user stories have already been identified.
Should All Teams Estimate
I’ve established that there are good reasons to estimate both the product backlog and the sprint backlog. And I’ve argued that these estimates should be in different units (story points and hours) and should be estimated at different times.
But do these arguments apply to every agile team? Or are there some teams who don’t need to estimate either or both backlogs?
I’ll share my thoughts on that in my weekly tip on Thursday. If you haven’t already, you can sign up to receive a short tip on succeeding with agile from me each Thursday.
