The Backlog

I had one of those "changing the way we work" discussions today, about the product backlog. I'll spare you the details, but it came down to answering two questions:

1. How many of the stories we know about should we have on the product backlog?
2. How many of the stories do we need to have estimated?

The answers, in turn:

1. How many stories? All of them
2. How many of them estimated? Some. Maybe.

The first answer was actually the most contentious - I'm still trying to wean everyone off multiple conflicting Excel spreadsheets each with only a small part of the picture on it, and change comes hard. However, there's a very simple reason for putting everything you know about on the backlog. It's your sole source of truth for all of the things you might want to do in future. There are a number of very good reasons for this:

• Access: everyone on the team can see the backlog. Ideally it's visible to your stakeholders too - everyone involved should have access (whether physical or electronic) to see what the team are building and the current priorities.
• Clarity: if there's one copy which is regularly updated, everyone has access to the latest information. You don't have the confusion of "I thought we were building this?" that happens when someone digs up a three-month old copy of an Excel worksheet or printout.
• Transparency: one of the worst things that can happen to an agile team is invisible work; requirements that are known, but not surfaced on the backlog. It makes it near-impossible to provide accurate estimates or realistic project burndown, which in turn makes it very hard to make informed decisions about when to cut scope or bring in nice-to-have features.

Now, at the start of the project some of those stories might be pretty vague. You may even have some 40 or 100-point epics where you know there's a large block of functionality needed but you're deferring getting into the detail as there are other, higher priority things to work on. That's fine - in order to plan out a release strategy all you need is to know that this isn't a quick 3-pointer, it's a big hairy epic that involves lots of work.

This last point gets us on to the next question. How many of those stories should have estimates?

Well... "some". "It depends". You need to take a judgement on how mature your team is with agile development, how consistent the size of your stories is, how much accuracy you need from your burndown, and how much time you're prepared to burn in planning (after all, it isn't free).

For teams starting out with something like Scrum or XP, or those who've tried but haven't done it very well in the past, I'd recommend a goal of having the whole backlog estimated. It's extra work, but at this stage your stories are likely to vary wildly in size (you'll have a run of 1s and 2s suddenly followed by a 40 and a 100) in a non-predictable way, and practicing the estimation process is worthwhile in itself.

Once beyond this, you can be a bit more flexible. You're looking for two goals:

• Have enough information to plan achievable sprints
• Have enough information to provide a burndown to your desired accuracy

What this means is that once you have a few stories estimated, you'll be able to gather a good idea of what the median size of a story is, and which ones are worth taking some time to estimate because they're likely to be contentious or unusually difficult. If you estimate or split up those difficult ones, you're left with a set of stories that you can assume to be "typical". This means that all things being equal, each one is on average a 5, or an 8, or whatever your median for "non-contentious stories" happens to be. It doesn't matter whether a run of stories is 3,8,8,3,5,5 or 5,5,5,5,5,5 - if you treat them all as 5s it comes out to somewhere near the same result no matter what the deviation. You take a hit that your estimate of delivery date is less precise, but on a project where scope is likely to change significantly it may save a lot of estimating stories which are only going to be thrown out. All you need to do is make sure everyone knows your figures are approximate, based on probability. (False precision is the enemy of good planning - it's almost always better to accept imprecision and plan based on a range rather than a fixed number).

As stories get closer to being picked up in a sprint, you may want to start estimating those "probably a 5" ones in more detail. Whether you do depends on how good the team are at writing stories and how good they are at assembling a coherent sprint without estimates. If your sizes are still wildly variant - lots of 1s and 13s in the mix - then estimating is going to be worth it. If you're often over-committing or under-committing on a sprint goal, then definitely estimate and task in more detail. If on the other hand your team have got to the point where almost every story is generally the same size and you usually get the commitment right then there's less payoff for estimating; you can probably build an achievable sprint without it.

Again, this is for teams who are old hands at the process. In your first few months, estimate everything and task it before it goes in a sprint - this will help you understand when to start skipping this level of detail in future.

Evidence

The key to all of this is that what we're trying to do with agile development is use an evidence-based methodology for delivering software. So what we're doing at an abstract level is this:

1. Gather evidence (put everything on the backlog)
2. Refine evidence (estimate what we need to)

We can then take that evidence and apply the team's velocity (itself another piece of evidence) to it in order to supply estimates of release dates that we feel comfortable about. It's easy to see from this that if you don't have all the stories, or you don't have enough estimates to make reasonable assumptions about the size of those stories, you won't be able to make any decisions that rely on knowing when you'll finish.

And that's really all we're doing here: the backlog is where we gather all the information that lets us know how much work we've got left to do. Making sure it's up-to-date and appropriately estimated keeps that assessment accurate.