Estimation and Velocity in Scrum

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.