How to Treat Unestimated Product Backlog Items

We all know that a product backlog is an ordered list of items we’re expecting to deliver, and it includes the estimate of the required effort to deliver each one of these items. We also know that only the team may estimate the items in the backlog. The Scrum Guide is very clear on this:

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

So what can ScrumMasters or product owners do when new items have been added to the backlog, but they haven’t yet been estimated? If we treat them as being 0-story-points big, we would be assigning them the only size we’re pretty sure they aren’t.

It is important that, as ScrumMasters, we aren’t tempted to put our own guesstimate on a story. We’re not allowed. Only the team is allowed, remember? Unless we’re doing the work, our estimates don’t count, regardless of whether it seems to be a trivial story and we’re pretty sure that the team would give it, let’s say, 2 points.

The most obvious reason for this is that it’s quite likely there will be challenges that we, as nondevelopers, can’t predict. Maybe this story touches parts of the code base that are horrible and unmaintainable. Maybe there will be a significant refactor needed as part of the work. Maybe the needed data isn’t available from the application programming interface that the application is integrated with, and so on.

Also, if we’re in a role in which we are keen for the story to get delivered quickly — for example, a senior stakeholder might be chasing us — we may be tempted to give the story a lower estimate than a developer would just so that we can make it happen more quickly (hint: we can’t).

Instead, let’s consider the following:

Why is there no estimate yet?

Has the team refused to put an estimate on the story? Did they say they needed to better understand the requirements and/or work involved? In that case, bringing a spike of the story (or a part thereof) into the next sprint might be a good way to make things clearer. Another option is to try to break down the story into smaller, better understood bits that are easier to estimate.

Occasionally, the team might also feel too busy to spend time estimating upcoming work. If so, have a look at why. Best case: The problem is temporary, in which case we can hopefully just hold off with the estimation for a week or two until things are back to normal. If it’s a consistent problem, we will need to find some way to allow the team to work at a more sustainable pace.

Do we really need an estimate right now?

Sure, the backlog is supposed to contain estimated items, but, in practice, we can often work around the absence of estimates for a while. For example, are we trying to predict what’s likely to be in a release far into the future? For now, it might well be good enough to just say something like, “In our experience, each major release tends to take the team about eight sprints. Here are some things we might be looking at in Release 5. The scope will get clearer closer in time, when we look in more detail.”

What is the cost of getting it wrong?

It is also important to consider the cost of getting the estimates wrong. If it doesn’t matter too much, we could go ahead with pretty much whatever method we like. We could always revise the estimate later. However, if important decisions are based on these estimates — like the scheduling of an expensive marketing campaign — we are likely to regret later that we didn’t take the time to make sure that the estimates were sufficiently reliable.

OK, it seems as if we’re clear that only the team can estimate stories and that we sometimes need to wait in order to get those estimates. Nevertheless, is there anything we can do in the meanwhile? For example, if the sprint has just finished and we’d like to update the release burn-down, then just ignoring the unestimated stories or waiting a few weeks might not feel like the best option.

Here are a few possible approaches we could take in the meanwhile, in order of increasing uncertainty:

Get only a couple of team members to estimate the story

Ideally, we want the whole team to estimate each story, because we don’t know who will eventually be working on it. It’s possible that someone will think of something that would affect the estimate that the others hadn’t thought of. Finally, just the act of talking about the story with the team is a good way to spread knowledge about the upcoming work.

If getting the whole team to estimate a story doesn’t feel like an option, just ask a couple of members of the team to estimate it for now. By asking at least more than one person, we will still get some of the benefits we’d be getting if the whole team were estimating.

Assume that the bits of a split story add up to the original story (but be aware that they might not!)

If a story has been broken down into smaller stories, and the original story had an estimate, it seems reasonable (but rarely entirely correct!) that the estimates for the parts would add up to the estimate of the original story. Depending on what we need the estimate for, this might be good enough for our purposes until the new stories can get properly estimated.

Assume that each unestimated story is of average size

A third, slightly more risky approach is to assume that each unestimated story is as big as the average story in the backlog. My team’s stories are, on average, 4 points big. If we add 5 stories to the backlog, chances are that we have added 20 points. It could be more, it could be less; but until the stories have been estimated, I have found it to be a reasonable guess. If using this method, we should err on the side of caution. It might be tempting to say, “All these stories are averagely sized, except this one, which is just a text change, so I’ll assign a 1 to it.” Our average will already include these small stories. On the other hand, don’t be foolish and assume that a new epic is the size of an average story.

To summarize: There really isn’t any shortcut that, as a product owner or ScrumMaster, we can take to make sure that each story has an estimate without getting the team to estimate it. There might, however, be some temporary work-arounds we can use until we get actual estimates. Used with caution, these can give us some indication for how much work is remaining on a release, but they can never replace the need for the team to estimate the stories.

Note: There is, of course, a completely different question: Do we need estimates at all? This is a wholly different discussion, outside the scope of this article, so use Google to search for #NoEstimates if you want to read more about that.