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:

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: