Your Best Product Backlog: Three Things To Do Now

product backlog process

I would argue the product backlog is the most important artifact in Scrum. Without it, you wouldn’t even get to the point of having a sprint backlog or a version of your product. It builds the foundation of the work you’ll do during the project. If your product backlog game is strong it can lead to wild project success, if it’s not it can lead to disaster.

So What Is a Product Backlog?

When people are first introduced to the product backlog they often compare it to a to-do-list…don’t be like that. A good product backlog has much more information than a traditional to-do list. The product backlog is also a lot more organic and fluid than a static to-do-list.

Think of your initial product backlog as a big old pile o’ logs, each log is a big old user story. Think of the project team as a really tiny little fire.

There’s an old saying that I heard growing up, usually on camping trips:

“White man builds big fire, stands back. Indian builds little fire, huddles close.”

You want your project to be as efficient as possible. We want to shoot for that tiny little, super efficient fire. The fire should burn constantly, consistently, and effectively.

Your project team can’t consume those gigantor user story logs yet. The logs (stories) need to be broken into smaller pieces before you can ever think of feeding them to your team.

scrum backlog grooming

To help you do this I’ve provided you with three things you can do right now to make your product backlog the bee’s knees:

TIP #1: USE AN AWESOME TEMPLATE

One of the main principles of Agile is providing mechanisms for transparency. Another is finding ways to adapt and adjust information. A good product backlog template can help with both.

A good product template should do a few things:

  • Keep your product and user stories organized
  • Display information in a clear and visually concise way
  • Provide an amazing tool for helping plan out sprints
  • Easily be made into a sprint backlog
  • Enable some high-level “pull” reporting on the progress of your project

Go To My Post About Sprint Backlog Templates

If you don’t know how you are going to create such an amazing template you’re in luck! Why re-invent the wheel?

tool iconTOOL: I’ve created a free editable product backlog template you can start using TODAY on your own projects!



scrum product backlog template

TIP #2: START POPULATING YOUR BACKLOG WITH USER STORIES

Now that you have your awesome free template you should start populating it with stuff that needs to get done. Remember, at this point, these are likely big old ugly user story logs with rough cuts and jagged edges. That’s ok, the important thing at this point is to get everything “logged” (pun completely intended). It’s important to err on the side of capturing everything so the team is aware of it and it doesn’t get forgotten.

Your product backlog can include all kinds of different things. Generally the types of items included in a product backlog fall within these four types:

  • Bugs
  • Features
  • Technical Work
  • Knowledge Acquisition

Fill in the backlog with any known information about the item such as:

  • The initial estimated story points
  • The priority
  • A high-level user story description
  • Whatever other relevant information you know

Again, it’s not important to know ALL the information now but you should fill in what you do know.

TIP #3: GROOM YOUR BACKLOG

The product owner should handle making sure the product backlog is regularly groomed. They should also ensure enough user stories are ready and prepared for the next sprint. Remember, we need to keep that small fire burning steadily. We need to have enough small pieces of wood ready to feed that super efficient flame.

The product owner can’t groom the backlog without input from the team. Because of this, it’s important that during a sprint the team set aside around 10% of their time specifically dedicated to backlog grooming. Teams should focus on grooming the higher priority and valuable user stories first. Ideally, the team will always have enough user stories for the next three sprints. For example: if your team’s velocity is 30 you need to have 90 user story points worth of stories ready to go.

It’s important that during a sprint the team set aside around 10% of their time specifically dedicated to backlog grooming.

It’s also important to try to keep your product backlog to a manageable size. We don’t want a product backlog that becomes unwieldy, unorganized and unmanageable.

There are so many ways to implement the three tips above. Stick to these three tips and find the way that works for your team. Do this and you’ll be well on your way to working efficiently and effectively with your product backlog.

I’d love to hear how this has worked for your team or even something entirely different that has worked. Please leave your comments below!