If you work in tech, it’s likely that your software or product development team uses scrum project management methodology (a subset of Agile methodology), where teams complete work in two-week sprints in order to continually develop a product instead of releasing whole products at once. 

But, as with any project management methodology, organization is key. And the scrum product backlog is an important tool to get you there.

A product backlog in Agile is, essentially, a list of items that are “on deck” for the development team. It’s a to-do list of items that need to be completed within a larger product. It’s worth noting that these aren’t items that you’re working on within the two-week sprint, but it helps you see what’s coming up so your team can plan and work quickly to release new features.

We’ll walk you through why the product backlog is important, how to develop and refine your own, and how the list plays into sprint planning.

What is a product backlog in Agile?

According to the official Scrum Guide, the product backlog is “...an ordered list of everything that is known to be needed in the product.”

The product backlog sits outside of the sprint loop (meaning it contains work that will not be completed during the current sprint) but informs how your sprint will be planned. The product backlog is composed of feedback from:

• The development team
• Customer
• Stakeholders

For an example of what a product backlog looks like, check out the product backlog example above. 

Why does a product backlog matter?

Think of a product backlog as a way of putting a brainstorm or a product plan into action. You’ll undoubtedly be approached by stakeholders (or customers) who have many ideas for improving the product. Not all the ideas are good and not all the ideas are valuable, but without an organized product backlog, it’s difficult to differentiate between the great, valuable ideas and the ideas that would only be a waste of time. Here are some other benefits of the product backlog:

1. It’s an organized list that’s easily wrangled.
2. It’s simple to prioritize.
3. It can be changed as priorities change.
4. It allows you to immediately see dependencies and order them.
5. It allows you to think about products in the long-term, not just in terms of immediate needs.

In short, a product backlog allows you and your team to make systematic, smart improvements to a product over the long haul.

What’s in the product backlog?

The Scrum Guide is fairly prescriptive about what can be in the product backlog, which is helpful for keeping unnecessary items out. The product backlog contains:

• Features
• Functions
• Requirements
• Enhancements
• Fixes

It’s not just a simple to-do list, though. Each item in the product backlog:

• Adds value for the customer
• Is prioritized
• Is estimated

There should be no low-level tasks in your backlog (like sending emails), and the backlog itself should be a living document that’s regularly rearranged. 

How to create a product backlog

It’s common for product backlogs to be presented in the form of a spreadsheet, but there’s a big problem with that: Spreadsheets aren’t meant to have their rows constantly moved. Plus, you’ll find yourself dealing with formatting issues and the ensuing migraine.

As you begin to create your product backlog, consider using a more flexible software solution such as Jira Software or Lucidchart. Lucidchart’s product backlog template is the easiest way to start building your scrum product backlog—it’s a living document that’s easy to share with stakeholders and rearrange however you’d like. 

Whatever solution you use, follow these steps to start your scrum product backlog.

1. Add ideas to the backlog

Stakeholders will typically be approaching you with ideas for product improvements

2. Get clarification

Once you’re approached by a stakeholder with a product addition or fix, make sure you understand:

• The reason behind the addition or fix
• The amount of value it contributes to the product as a whole
• The specifications of the item

3. Prioritize

The backlog should have clearly defined, high-priority items at the top and vague items that are not a priority at the bottom. If an item has no value, it should not be added to the backlog. 

4. Update the backlog regularly

The backlog is a living document; make sure you’re constantly prioritizing, refining, and keeping the backlog up to date.

You may have hundreds of items in your backlog as ideas for product improvements are suggested. Some of these items may be discarded, but many of them will begin making their way up the backlog for further refinement and, ultimately, development.

Get started quickly with a customizable product backlog template.

Product backlog prioritization

The product backlog itself is owned by the product owner. The product owner’s job is to produce the very best product possible, so that means developing the most valuable additions to the software first. Since the product backlog is ranked in order of most valuable components, it would stand to reason that the most valuable addition would be at the very top. But that’s not necessarily the case, as the most valuable addition likely has dependencies that need to be developed first. 

Higher-priority items should be refined and have great value to the product.

Mid-priority items should be candidates for refinement (the process of detailing each task)

Low-priority items should not be a dependency and can be safely ignored until they are candidates for refinement.

As items progress closer to the top of the list to be added to the next sprint cycle, they should be refined so they can be better acted upon. Here’s a helpful tip: color-code each block to indicate an item is sufficiently refined and ready for sprint planning by coloring it green. You may wish to indicate mid-priority items with yellow and low-priority items with red. Or go crazy and make everything neon.

Product refinement

Product refinement is the process of refining the tasks in the product backlog so that they’re clear enough to be action items instead of nebulous ideas. 

Say your team is developing a dating app. One of the requests from stakeholders and customers has been to have an integrated background checker, so you add that to the product backlog. However, that’s not nearly defined enough to start assigning tasks for developing the background checker. 

Add necessary details right in each task of the product backlog so there’s never any confusion about what each item is. For instance, with our dating app background checker, you can easily detail what kind of agency you’ll be pairing with to provide a background check, what information should be gathered from the user to perform the background check, and what the ultimate goal of the background check should be. You can also easily add links, pictures, or any other information.

There are two schools of thought with product refinement: Some teams prefer to refine all the items in a product backlog while others prefer to “groom as you go,” refining mid-priority items so they can be elevated to high-priority items.

Sprint planning

A scrum product backlog ultimately makes sprint planning much easier. After all, your to-do items are already defined for you in the backlog, and they can be easily moved onto your scrum board. Using each item’s estimation allows you to determine how many action items can be added to the next sprint. Then it’s a matter of following the sprint cycle guidelines to follow each item through to completion. 

A product backlog provides a bird's-eye view into upcoming items that can be added into the product, but its value really shines in its ability to organize, refine, and define action items. Ultimately, you’ll be allowed to focus on systematically adding value into your product instead of trying to sift through the chaos. Get started building your product backlog in Lucidchart and see how easy it is to share, update, and change this vital component of your development process.