Mastering your product backlog

This article is an excerpt from our new 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. Is it easy? No. But by sticking to a few best practices, it gets a lot easier.

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

Do I need a product backlog process?

Yes. Don’t fight us on this one.

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

Don’t worry, though. Building a process is really easy.

How we run our backlog

Here's how the ZenHub team does it:

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 (ie. it needs more detail or the team has no capacity for extra work), the issue is dragged 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. Simple.

What makes a “good” product backlog?

Focus on making it DEEP.

Detailed appropriately.

The closer the issue is to the top of your backlog, the more detail it should have.

Estimated.

Your product backlog is more than a to-do list; it’s a planning tool. Issues at the top should have precise estimates (by time, complexity, or whatever works for your team), whereas tasks further down don’t need to be as specific.

Emergent.

In a backlog, time, budget, and quality are all fixed variables. Scope is not. Backlogs are emergent, meaning issues will be “frozen” in the Icebox, closed, added, or edited as you learn more.

Prioritized.

Issues should be vertically arranged according their business value.

What’s the customer’s role in a product backlog?

You know the expression “the customer is always right”?

Besides being a source of agony for folks in retail jobs, the expression applies non-negotiably to your product backlog. Customer feedback should be the biggest influencer of what you work on, and when you work on it. In agile development, the customer’s needs, wants, and feedback informs all the requirements on a project.

Your ideal customer is an expert in your subject matter. They should be...

• Familiar with your business
• Deeply invested in what your product does, how it looks, and how it works. After all, your product is solving a significant need in their life.
• Committed to guiding your team and answering questions thoughtfully.

Naturally, only your development team knows how other factors, like potential technical debt, will affect how that feedback should be prioritized.

Keeping 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 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 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 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.

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.

We find team-wide product backlog meetings laborious and generally unproductive. We think developer efforts are better spent actually developing, and that refining by committee can introduce clashes, misaligned objectives, and other potential time sinks.

When should you refine a product backlog?

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

Pssst! If you haven't already, download ZenHub free to get task boards, epics, and more – directly added to GitHub.

This is the third post in our series ZenHub on Project Management. Check out our first article on agile project management in GitHub or the second article on using epics and milestones the right way.

If you enjoyed this post, share it with your friends! (Twitter's great for that.) 🐦