Product backlog management: how to manage and refine backlogs

Editor’s note: This article is an excerpt from our newly revamped eBook: Project Management for Teams in GitHub. For the full guide to building a high-performing, agile software team, pick up your free copy!

A product backlog is the culmination of feedback from multiple sources, like the developers, prospects, management, marketing and, most importantly, your customers. It’s your job to take in that feedback, prioritize it, manage it, and work it into the future of your product.

But is it easy? No. By sticking to a few product backlog best practices, it can get a lot simpler.

Why does it matter? A (well-managed) backlog leads to more productive and more meaningful work. The result is a better product that your customers actually want to buy.

What Is a Product Backlog?

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. The product backlog is driven by the product goal that usually is associated with a product release.

This list includes all the features, feature changes, user stories, bug fixes, non-functional requirements, enablers, and other activities that need to be acted upon. This represents the work the Product Owner believes needs to be completed in the upcoming sprints. Meanwhile, the activities for the current sprint should be placed in the Sprint Backlog. In Zenhub, you should use the columns for To Do, In Progress, or Completed work to track progress.

If you will, the backlog is a source of truth in case the information doesn’t match other product documentation. This makes the process of refining your product backlog even more important.

But how’s the product backlog different from a simple to-do list?

If we were to consider the backlog as a to-do list, it would be fairly easy to confuse it with the To Do column in your Kanban boards. The latter strictly refer to tasks that need to be done within a given time frame (i.e. a sprint for Agile teams).

Here’s where the first core difference appears: backlog items don’t provide the final tasks. The product backlog can change at any time as new requirements and challenges appear. A to-do list, on the other hand, should include the exact activities your team should execute based on the latest information they have.

Additionally, action items on a to-do list tend to be completed within a relatively short time frame. At the same time, the product backlog contains everything that needs to be done over multiple sprints and doesn’t prompt immediate action. So a task goes into the to-do list only if the team has the capacity to take over a task that’s awaiting its turn in the backlog.

This concludes that backlogs and to-do lists have different purposes as well. Backlogs aren’t there to show employees what’s on their work tray. That’s what to-do lists help with. Product owners instead use them to prioritize work and maintain an overview of what the team is most likely to work on in the upcoming Sprints.

Who is responsible for product backlog management?

A single-point person – the product owner – is accountable for effective product backlog management. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.

The product owner can pull in developers, stakeholders, and customers as needed during the discovery process. However, developers who will be doing the work are also responsible for understanding the items in the product backlog as they need to size the efforts required to complete them. We find team-wide product backlog meetings laborious and generally unproductive.

Why Is a Product Backlog Important?

The product backlog shows its real value when it comes to executing an action plan. With so many ideas as to what the product development process should look like, the backlog saves the day by helping you organize all tasks and establish their order and priority before it’s time to work on them.

And this is exactly why you need a product backlog: to put all ideas in order in a timely manner. Once you’ve got your priorities in place, it’s easy to get back to your backlog and change a task in case of new product priorities. This also gives an overview of potential task dependencies and future extensions as backlog tasks are highly susceptible to change.

How to Tell if You Need a Product Backlog

You must have one ready at all times. Don’t fight us on this one.

Without one, your backlog will become clogged with actionable feedback. Double-work is created, visibility goes down, and focus is eventually lost; it all adds up to a demoralizing experience.

When Should You Refine a Product Backlog?

There’s no right answer here; your team should develop a cadence that works for you. We try to do it a little every day, but as a focus, we refine it around two days before a Milestone begins.

So what makes a “good” product backlog when teams are so diverse to begin with?

Start by Reviewing What Issue Types You Work With

Most teams have habitual types of Issues that get created, for example: bugs, feature requests, tech debt, user stories, etc.

To streamline continuous refinement of Issues, we recommend documenting common issues that you create. This helps standardize the info you look at, by Issue type, when refining those Issues. In addition, discuss how you determine priority for each of these Issue types. What does low, medium, high mean?

Ensure the priority buckets (however, you define them) have a shared team meaning. Is there a criteria you can use for each level of priority?

For example: High priority is only used when a customer is blocked from using the product or there is X amount of business revenue affected.

However, what’s more important than priority is order in the product backlog. There can only be one number one, one number two, etc. That way the team always knows what’s the next big thing even if the product owner is not around.

The more concrete a criteria for defining order and priority and needed info per Issue type, the easier it will be to distribute planning of projects and prioritize work that needs to be done without conflict of what needs to be worked on, in what priority.

Use Issue Templates for Common Issue Types

Once you have your Issue types documented, use GitHub’s multi-templates so the team can ensure relevant information never gets missed when creating Issues in real-time.

It’s easy when creating new Issues to forget to add info. With a template, regardless of who creates project Issues, the team has a shared understanding of important details that complete the Issue.

This is also helpful to save hours against project interruptions. For bugs, a template ensures effective info gathering and standardization for potential sprint interruptions. Robust bug reports ensure interruptions are effectively prioritized based on a robust suite of data.

Learn how to create Issue templates in GitHub and ZenHub.

Separate Your Product Backlog from Your Sprint Backlog

By separating the product backlog from the Sprint backlog, we notice teams communicate the priority of work more effectively. You’re able to split up:

• Work that is sprint-ready, but not yet accepted and planned into the upcoming Milestone (Development backlog)
• And work that has been accepted into the upcoming Sprint (Sprint backlog).

Keep Your Backlog Healthy

A well-maintained product backlog might be the single biggest gift you can give to your users – and your sanity. The point of “backlog refinement” isn’t to create a needless process, but to make space for a more focused product. Think of it as clearing smog from your team’s North Star.

Backlog refinement accomplishes a few things:

1. It provides order and prioritization, giving clarity and direction to everyone involved.
2. It ensures customer feedback is observed and integrated into the product.
3. It prepares issues for the sprint, giving each issue a clear, concise, and testable foundation for developers to work from.

Our better-refined backlog resulted in shorter planning meetings, an increase in planning efficiency, and smaller, more focused issues.

Run Effective Product Backlog Refinement Meetings

While every software team operates effectively based on their own workflow, rhythm, size, and practiced project management philosophy, we share a few tips we’ve heard from teams on what works for their refinement sessions:

Note: Backlog refinement meetings are not mandatory in Scrum.

• Have product backlog refinement meetings (typically 1-2 hours) on opposite weeks of sprint planning. This breaks up long meetings and gives product/stakeholders buffer time to answer questions about upcoming work before it gets accepted into a Sprint if something about a project is still unclear.
• Have the entire development squad and the product owner in attendance. Anyone who’s going to be working on the project work or issues being discussed should attend as well as anyone who has important information about the work items. For example, you can invite subject matter experts to discuss specific topics, walk through the issues, and get some answers.
• Things to cover in the meeting: Spend the meeting reviewing upcoming pieces of work, breaking Issues down from large stories to development tasks, discussing if the top of the backlog is still ordered correctly, as well as estimating new pieces of work. However, don’t go too much into details or too far into your product backlog as things may change the farther you are from working on them.
• End by reviewing if the placement of Issues in your backlog pipeline is still relevant. Keeping this pipeline prioritized helps teams understand the most important issue to work on next should everything in the Sprint be finished ahead of time.

Prioritize the Top 20% of Your Backlog Pipeline Using ZenHub

In ZenHub, we recommend the following rule of thumb for best organizing your product backlog in a Workspace: everything in the top half of your backlog should be prioritized starting with the most important upcoming Issue on the top. Everything at the top should be spec ready, have clear acceptance criteria, and be estimated.

Everything that is considered a priority, or in the top 20% of your backlog should also have an estimate. If your estimate is large on any of the Issues in your top 20%, consider breaking down this work into smaller stories and tasks in your next agile backlog refinement session.

How We Run Our Product Backlog

Here’s how we manage our product backlogs at ZenHub:

1. New feedback and ideas automatically land in the New Issues pipeline.
   Our product owner scans each issue and quickly decides whether each task is actionable. Note: When we say “product owner”, we mean whoever makes the ultimate call as to what is built and when.
2. If we intend to complete an issue but it’s yet not ready for development (i.e. it needs more detail or the team has no capacity for extra work), the issue is dragged into the Backlog. Issues here don’t yet have a Milestone. You’ll add one at the beginning of a sprint.

• If it’s a valuable issue but we have no plans to add it to a Milestone, we’ll freeze it in the Icebox. This keeps our backlog from getting bogged down.
• If the issue isn’t going to get done, we close it completely. Don’t get too precious about this: you can always re-open it.

3. Is the issue ready for action? At this point, our team has added details (like acceptance requirements) and a user story (the what and the why.) Our engineers have added an estimate. Once an estimate and a Milestone have been attached to an issue, it’s formally part of our “Sprint Backlog.”

4. When the sprint begins, we simply filter the Board by Milestone. Individuals grab whatever is on top of our backlog and drag it to In Progress to indicate it’s being worked on.