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.
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.
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.
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.
© 2021 Digcode.com