What goes into the product backlog?

To keep clutter at a minimum, your team’s product backlog should only house work that directly affects the finished software. This means new features, bug fixes, technical debt and small updates will all be grouped together as “user stories” to build the backlog’s foundation.

Here’s an example of a user story we might use in a new application:

c/o Axosoft Scrum Software

At this point the concept doesn’t need to be very fleshed out- it just serves to stimulate conversation about what a feature might look like when it’s implemented.

Prioritization

Once the user story has been created, we need to determine its priority level. The product owner is in charge of this task and will come in to decide whether our feature should be at the top of the backlog, near the bottom or somewhere in-between.

c/o Axosoft Scrum Software

After priorities have been set, we’ll want to start working with the product owner to shape how the most critical user stories will feel and function in the final product. Ideally he or she will come in with a detailed description already developed, but the dev team may need to provide some guidance on the technical aspects.

Okay, so we know how our user stories will be implemented and the general order of execution- now we need an estimate that will determine how long each one will take.

Making Good Estimates

Good estimates are probably the most important part of the backlog because they determine how many user stories a team will take on during their sprint. This task is equal parts art and a science, so it’s very common for new Scrum teams to over-commit their first few sprints. Don’t worry about it. Instead of padding the estimates as a way to inflate your team’s sense of accomplishment, start keeping track of their true workload with these tips:

• If a user story seems too big to estimate accurately, break it up into smaller items. That way your team can attack it in pieces and potentially spread implementation of the full user story throughout multiple sprints.
• Sprint backlogs should be as independent from each other as possible. Creating dependent backlog items can negate the work you’ve done during the release planning process and add a layer of complexity that doesn’t need to exist. If there’s no way around it, incorporate sequencing into the priority system, but the fewer moving parts you have the better.
• Your estimates aren’t about the time it takes to complete the work. It’s about how much work can fit into a sprint. Realize that a feature estimated at three days may take a new developer five days to finish, but an experienced developer two days. Rather than focusing on each estimate’s accuracy, try to get a gauge for the average number of hours your team can handle as a whole, per sprint.
• Don’t estimate low priority backlog items. Developer time is precious, so start estimating from the top, and work downward until you’ve planned enough items to fill the next sprint. The rest of your estimates can wait until they become more relevant later on.

The Definition of “Done”

As your team starts working through backlog items, the last thing you’ll need to know is how to determine when they’re done. Yes, this sounds simple, but your team can trip up toward the end of a sprint if there isn’t a universally accepted understanding of what it means to complete a user story.

For example, Bob the developer might tell you the laser gun user story is “done” because he’s finished coding it, but has it been tested? Reviewed? To make sure everyone is on the same page, most teams develop a brief checklist that outlines the sprint’s Definition of Done. Usually this list will ensure an item has passed through the appropriate workflow steps, received a final level of review and is fully ship-ready.

Takeaways

• A product backlog is the long list of things that must be done to successfully create a software, and the backbone of your Scrum execution.
• Only the work that directly affects your finished software should be in the product backlog.
• Your product owner determines the priority level of each backlog item and how the most critical user stories will function in the final product.
• Estimates help teams figure out their workload capacity and are probably the most important part of the product backlog.
• To make sure everyone is on the same page, your team should develop a brief checklist that outlines a sprint’s Definition of Done.