Breaking Down the Scrum Product Backlog

You'll hear me mention this a lot because I don't think it's given enough credence elsewhere:

The Product Backlog is the backbone of implementing Scrum successfully. Properly sizing the backlog items, creating good estimates, prioritization, and creating a definition of done all play into the product backlog and having all of these will make your life easier in a number of different ways.

So what goes into a successful product backlog? It's going to be the work that directly affects the final product and only the work that directly affects the product backlog. This means new features, bug fixes, slight tweaks to the interface and technical debt. All of these things are (usually) treated generically as simply "Product Backlog Items" (they're also sometimes called User Stories but that's another post).

So let's create a backlog item. We'll start by writing up an idea of what we want in the application:

It doesn't need really need to be much at this point, really just a name to stimulate conversation about what it will look like when it's implemented.

Now at this point, we need to know if this backlog item is important. This is where your Product Owner will come into play, he'll decide if this should be at the top of the backlog or near the bottom or somewhere in-between. In short we need to know the priority of these backlog items.

Ideally at this point the product owner would also give us a detailed description of what this will look like when it's implemented but they may need some guidance or feedback from the development team to know what to define.

Now you need an estimate and this is probably the most important part of the backlog. Good estimates allow you to commit to just the work that you can get done in a sprint and very often over-committing is a great way to fail your first few sprints. While I can't guarantee that you'll do this right when you first start estimating I can say that padding your estimates is most definitely something you'll want to avoid. Here's a couple things to keep in mind when estimating:

• If a work item seems too big to estimate accurately, break it up into smaller work items. You can attack it piecemeal from there and you'll also get the added bonus of implementing a backlog item over the course of multiple sprints if need be.
• Each backlog should be as independent from the others as possible. Try to avoid creating dependent backlog items as this fuzzies up the straightforward approach we're going for and adds a whole other layer of complexity that doesn't need to be there. If you absolutely need to, make the sequencing of your work items part of the priority system. The fewer moving parts you have the better.
• Your estimates have nothing to do with actual time. This is important, your team may estimate a sprint's worth of backlog items at 1000 hours and then finish early (or not finish, that's another article). That's okay, simply plan more work for the next sprint. What's more, a 3 day feature may take a new developer 5 days to finish or an experienced developer 2 days, that's okay too. Accurately estimating the backlog has more to do with how much work can fit into a sprint than it does making certain that our estimates are accurate. (Remind me to write about estimating in story points soon)
• Don't estimate low priority backlog items. Developer time is precious and while we might get to the bottom of the backlog someday for right now we're strictly concerned the work that might make it into the next sprint. Start estimating from the top and make your way down until you're comfortable that you have enough to plan the next sprint. Descriptions may change for lower priority items or new higher priority items may be added before the next sprint, don't worry about it for right now.

So that's really all we need in a product backlog item. Build your backlog with that info and you've got a great start to your first sprint. Next on the docket: Sizing your backlog items and estimating.