Creating Effective Product Backlogs

Creating a product backlog is a classic case of “easier said than done.” A product backlog is a list of product improvements that your team needs to execute for your product strategy to become a reality. What makes this idea challenging is that sometimes, a product backlog can morph into an unending list of ideas that aren’t always fully vetted.

Obstacles When Creating a Useful Product Backlog

Three things might prevent you from creating a useful product backlog:

1. Backlogs can quickly become overwhelming.

If you list every product improvement that you need to execute, you might end up with 1,000 product improvements on one list. That’s not manageable.

2. Traditional backlog structures can create confusion.

Many product backlogs use user stories to explain the product improvements that are needed. User stories don’t create alignment and can be interpreted in different ways by different people on the product team.

3. Until recently, there haven’t been tools explicitly created for backlogs.

Product backlogs have traditionally been managed in tools not designed for product management. Product managers often manage their backlogs in Jira or, worse, a spreadsheet.

Best Practices for Effective Product Backlogs

To avoid those three problems, follow the five rules of effective product backlogs. Without these rules, you risk turning your backlog into an untenable mess.

1. Make product backlogs a living document

A backlog isn’t something you create once and then let it waste away in a shared Dropbox folder. Instead, it should be a living document, which means you need to update, prune, and sort it regularly. Find a way to make it a regular process by adding weekly or biweekly events to your calendar to review and update the backlog.

Living documents take work to maintain. It’s like the difference between a book and a blog: Once a book is published, you rarely update it. However, you update blogs regularly. You publish new posts and refresh old posts as new information becomes available.

If you’re following the three pillars of Product Excellence, creating a dynamic backlog isn’t difficult. Since you’re continually listening to your users and refining your strategy, your priorities will change. As those priorities change, your backlog will need to change too.

Say that a data-export feature was a medium priority when you first created your backlog. Over time, you implemented higher-priority changes to your product. Perhaps those releases solved some or all of the original data-export feature, or maybe they negated the need for it altogether. Without actively assessing your backlog, the data-export feature will sit there, and at some point, people will ask why it’s there and if it still needs to be developed.

2. Put specific limits on your backlog

It can be easy to let your product backlog get overloaded with 500+ feature ideas and bug fixes, but your backlog shouldn’t be the place where you store every feature idea that you’ve ever devised.

Instead, focus your backlog on the product improvements that are likely to make it into development soon. If you include items that won’t get put into production for another year, you’re just adding unnecessary clutter.

That is, unfortunately, easier said than done. To help keep your list lean, you should do two things:

Sort potential features by category.

Categories can help you quickly understand why something is a priority. Quickly understanding product priorities will stop you from adding improvements that aren’t a priority to your product backlog. For example, if you have a handful of security features that need to be fixed as soon as possible, categorizing them as security updates will help you keep track of them.

Limit the backlog to a short time frame.

If you work in sprints, keep your backlog focused on the current and upcoming sprint.

3. Use prioritization scores

Prioritization scores will help you quickly sort essential product improvements. These scores are made up of at least two inputs: complexity and user impact.

Each product feature should be given a score for user impact, explaining how much the product improvement will affect your users and a score for complexity. Complexity rates how difficult and time-consuming it will be to build the specific product feature..

If you’re not accounting for those two inputs, you’ll probably end up prioritizing ideas that are complex and won’t impact your users in a significant way.

Ideally, your top-priority product improvements should be the ones that are simple and have a high impact. Once you’ve worked through those features, you can move down the list to lower-priority items.

After using prioritization scores for a while, you’ll be able to set benchmarks for what belongs on your backlog and what doesn’t. You’ll understand that if something has too low a score, it’ll never make it into production. Therefore, that product improvement idea doesn’t belong in your backlog.

4. Don’t list improvements as user stories

A lot of product backlogs are written in a user story format. For example, you might see a backlog with items listed like this:

• As a site visitor, I should be able to register with Facebook or Twitter.
• As a registered user, I should be able to save articles to read later.
• As a registered user, I should be able to opt-out of seeing advertisements.

User stories like that can work for customer-facing features because they’re specific, and it’s easy to understand why the product team is creating each improvement. But when it comes to technical improvements — like bug fixes and security patches — user stories are less useful.

For that reason, you might consider avoiding user stories altogether for the product backlog. You can use them as context for the backlog, but the backlog itself should focus on the specific product improvements, not the story.

5. Use a product management tool

If you’re managing your product backlog in Jira or a spreadsheet, you’re making your product team’s life more difficult.

Jira is a development tool created for developers. When you add product management into this tool, it quickly becomes cluttered. We’ve had customers tell us that once they pulled their backlog out of Jira, the tool became more useful for the development team.

A lot of other teams use spreadsheets to manage their backlogs. These can work, but they usually end up creating more work for you as the product manager. The problem with spreadsheets is that they lack a crucial piece to product development: context.

Without context, it’s easy to forget why you gave each product improvement it’s feature improvement. Product management systems avoid this altogether by allowing you to tie context to each improvement. You can add notes from customers and input from company stakeholders, and you can get more detailed on the prioritization scores.

With those pieces, you’ll be able to understand why you prioritized each feature the way you did. They will also help provide context to your engineering team, which will help them buy into the product improvement they’re developing.

Manage your backlog like a product

For a product backlog to be effective, you should manage it like it’s a product. Giving it constant attention will help your backlog be a streamlined tool that aligns your team.

Luckily, if you’re using a product management system, backlog management becomes easy. A good product management system will have prioritization scores and context built-in. Not to mention that product management systems allow you to update your backlog with greater ease.

.     .     .

Productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, Productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a free trial of Productboard today.