The product owner’s guide to product backlog management

We’re a fan of product backlogs, as you can probably tell. After all, we named our project management software after them! But what is a product backlog, and why are they so useful?

A product backlog is essentially a prioritized task list of everything that needs to be done within a project. If a job isn’t listed on the backlog, then it doesn’t get done.

The product owner is in charge of the task list, including its content and order. But — and this is important — unlike traditional team schedules or to-do lists, the product owner isn’t in charge of defining when each individual task is to be completed. That’s down to the team members.

How a product backlog boosts your team’s productivity

A product backlog makes both developers’ and product owner’s lives easier; instead of the dev team working at someone else’s pace and having work pushed on them, they can instead look at the product backlog, work out which jobs need to be done in what order, and pull jobs from it when they’re ready. This means they can focus on doing the best job they can, free from the stress of unrealistic deadlines and frequent interruptions.

Because everything is transparent, product owners and other team members alike are always up to date on work. This greater level of openness helps with iteration planning, as well as budgeting and expectation management.

Kanban vs. Scrum: Different ways to run your backlog

There are two main ways of working through your backlog list. You can either take a Kanban approach, which requires the team to continually pull jobs through and communicate in real-time. Or you can implement a Scrum way of working and pull jobs through iteratively.

The Kanban approach is highly collaborative: Team members pull jobs through and share tasks equally, free from any predefined roles. It’s particularly good for iterative improvements and projects with widely varying task priorities.

Scrum, on the other hand, sees the project management group tasks together in batches (known as ‘sprints‘), each of which has its own set completion date. So while team members still pull jobs through at their own pace, they have their own defined roles and work toward an overarching deadline. This offers a more defined, structured way of working and is best suited to projects where the priorities are stable and are unlikely to change much over time.

How to create a product backlog

First, create a roadmap. This is essentially a way to give your team context; it should show your team how the product will evolve and grow and include all the information about product functionality, features, and timelines. The roadmap is a top-level document that should give a broad overview of the entire project.

Roadmap features are then broken down into milestones. Milestones, like sprints, are made up of smaller tasks that contribute to the overarching project objective. After the team has completed one milestone, they’ll move on to the next.

Milestones are traditionally shown as a feature, accompanied by a short one- or two-line description, which is expanded upon in user stories, i.e., descriptions that help define the benefit from a customer’s perspective. Here’s an example:

“As a <shopper>, I want to <see my shopping cart before checkout>, so I can <review my items before I pay>.

The words in bold are the variables. They change depending on your goal or business, but the format remains the same whether you’re creating a user story for an e-commerce site, a government form, or anything in between.

Essentially it should define the user, the action, and the goal, so the person working on the task knows what they have to do. Most importantly, it should define why it’s valuable to the end user.

What’s the difference between milestones and epics? Milestones are fixed in scope and are used to track tasks and issues according to time. Epics, on the other hand, track issues and bugs according to the subject.

How to prioritize your product backlog

It’s tricky to prioritize when everything is urgent. But if you’re a product owner, it’s all in a day’s work.

It’s the product owner’s job to decide on the priority order based on factors like customer need, implementation difficulty, task dependencies, and feedback urgency while keeping a good line of communication between all parties to optimize planning.

In terms of the task order, there’s no right or wrong way, and many choose to mix and match depending on their priorities. Sometimes, the product owner may want to deliver a complete epic first. At other times, they’ll pick and choose certain stories from different epics.

That’s the beauty of having a product backlog and a roadmap; the backlog means everyone can see and control progress, whereas the roadmap provides that all-important context.

Defining long-term and near-term jobs

As the backlog gets bigger, it becomes necessary for product owners to group tasks according to their near and long-term status.

Near-term jobs are fully fleshed out with complete user stories, cross-team collaboration plans, and estimates in place. Longer-term items tend to be more loosely defined. If you do have information to add, provide those details as early as possible.

Remember, even rough estimates and plans are helpful (just remember to state their ‘roughness’ so people know the estimates are likely to change).

How to make your product backlog a success

1. Keep it well organized and updated. Product owners should review the backlog with the addition of every new feature and iteration to make sure everything’s prioritized correctly and that feedback has been incorporated. It should be a reliable source of information for your dev team.
2. Don’t create multiple backlog lists to track bugs. It’s easier if the dev team is all working from one unified list. If you have multiple teams, create one list per team rather than several lists for one team. Keep it simple!
3. Close jobs and issues. If your team won’t have time to work on something, create a protocol for setting it aside for later. If you’re using Backlog, you can either list it as ‘resolved,’ close the issue and reopen it later, or set a date for it to be followed up on as needed. Simple!
4. Re-prioritize jobs. If you’re a product owner, feel free to re-prioritize tasks according to new requirements and customer feedback. But remember to keep changes to a minimum so as to not disrupt the dev team and their focus.
5. Encourage conversation. Stakeholders and dev team members will challenge your priorities. You may want to challenge the dev team about their task completion speed. Use this as an opportunity to shape your planning and get everyone on the same page.

Backlog grooming is sometimes called backlog refinement, but they both mean the same thing: keeping your backlog tidy, organized, and up-to-date. Whatever you call it, smart product owners keep their product backlog well-tended.

Challenges to backlog management

If backlog management is such a benefit, why isn’t everyone already doing it? And, if you’re searching for how to get started, why haven’t you been grooming your backlog already? The ugly truth is that there are some challenges to getting started. But, don’t worry, we’re here to start getting those cleared up so you can hit the ground running!

1. Cost. Grooming your backlog takes time, and, as we all know, time is money. Especially when you’re just getting started, your backlog may look impossible to get in order. But fear not! You’ll be able to get through it, and after completing it once, it’ll be much simpler to work through as more items are added in the future.
2. Insignificance. When you look at every single task and subtask at once, it’s easy to see them all as being insignificant. You have nothing to measure these items against. Does it really make a difference if you remove this one or that one? The answer is: YES! If it seems difficult to judge importance at first, have a conversation with the PM or the people the tasks are assigned to so you can better gauge them before you start moving and deleting items.

Final thoughts

It’s the product owner’s job to define the priority of task items. And it’s the dev team’s job to dictate the task completion speeds.

For product owners who are used to defining both priority and speed, handing the latter over to the developers can be tough; it requires a hefty dose of trust, something that’s even more of a challenge if the relationship is a new one.

The key to taking the stress out of this situation is — you guessed it — a healthy helping of communication. Using project management software, like our Backlog, keeps that flow of communication strong with things like work-in-progress statuses, real-time notifications, version control, and time-management features. When it comes to product backlogs, it’s simple: The more transparency, the better!

This post was originally published on April 10, 2019, and updated most recently on March 30, 2021.