This article includes excerpts from our Better Software & Stronger Teams book. For the full guide to building a collaborative software team, pick up your free copy!
A product backlog is the culmination of feedback from multiple sources, like the development team, 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 a list of all the tasks that need to be completed before a product release.
This list includes all the features, feature changes, user stories, bugs fixes, and other activities that need to be acted upon. Note that everything that goes into the backlog will be completed during upcoming sprints. Meanwhile, the activities for the current sprint should be placed under a To Do, In Progress, or Completed state instead.
If you will, the backlog is a source of truth in case the information doesn't match across 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.
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 an 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 upcoming sprint duties.
Whose Job Is It?
A single point person – the product owner – should be in charge of backlog refinement. They can pull in developers, stakeholders, and customers as needed during the discovery process.
However, we find team-wide product backlog meetings laborious and generally unproductive. Developer efforts are better spent actually developing and backlog refinement tasks can introduce clashes, misaligned objectives, and other potential time sinks.
Why Is a Product Backlog Important?
The product backlog shows its real value when it comes to executing upon 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 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 grooming 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.
The more concrete a criteria for defining 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.
Separate Your Product Backlog from Your Sprint Backlog
By separating the 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 committed to, and 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:
- It provides prioritization, giving clarity and direction to everyone involved.
- It ensures customer feedback is observed and integrated into the product.
- It prepares issues for the development team, 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:
- Have scrum 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 in attendance. Anyone who’s going to be working on the project work or issues being discussed should attend. You should also have the Product owner / Design owner attend. Product and Design walkthrough the Issues in the product backlog and help answer questions as things get discussed.
- 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 prioritized effectively, as well as estimating new pieces of work.
- 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:
- 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.
- 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.