Let’s talk tactics. How do you prioritize your product backlog today?
If you’re like most product managers (read: busy!), you probably don’t have much choice. You treat it like a dumping ground for every idea, story, feature request, bug fix, and task related to your product. These items are coming at you constantly, after all, and you have to capture them someplace, right?
You probably also don’t have much time to organize all of these product-related to-do items before adding them to the backlog—to weigh the strategic value of each against the resources it’ll take to complete, for example. So, if you’re like many of the product managers we at ProductPlan talk to, you probably find that your product backlog has become a black hole.
What Your Backlog Is (or Is Supposed to be)—and Why You Need to Prioritize It
But let’s step back: Why are you maintaining a product backlog in the first place?
Ideally, your product backlog should be a list of every product-related task your team needs to complete next, and everything they can and should focus on (within a defined time-frame) after that.
Beyond that point, however—once you get below, say, the second level of priority—the items on your backlog can quickly become a problem because they bloat and clutter the list, making it more difficult to review and organize.
This is why it’s so important to prioritize your product backlog—to make sure it doesn’t become an open-ended list of every random thought anyone has about your product. Your backlog needs to be structured, organized and arranged to favor the most strategically important things for your team to work on.
Hint: If someone in your organization (including you) can say, “Let’s just throw it on the backlog,” and that sounds like a viable idea, you have a problem.
We at ProductPlan are passionate about helping product managers stay organized and able to focus on their strategic vision. And other than poorly executed product roadmaps, we’ve found that ineffective backlogs are often the biggest hindrance to a product manager’s ability to successfully drive a product forward. We even hosted a webinar offering tips to connect your strategic roadmap to your backlog, with our friends and integration partners at Atlassian Jira.
We encourage you to watch that webinar. For now, though, let’s discuss some practical tips for prioritizing your backlog.
7 Tips to Prioritize Your Product Backlog
1. Determine a bucketing system for organizing items on your backlog.
When organizing your backlog items, it’s helpful to set categories that each item will fall under. What you choose to name these categories matters less than the purpose—to give you a clear view of what needs to be prioritized. The backlog feeds what teams will work on during each sprint, so you need a system that empowers you to quickly find exactly what you’re looking for.
Some example categories:
Once you determine the categories your team will use, you can neatly organize and slot in items. Let’s take a look at how this would look in practice:
Step 1: Organize backlog items by category
Now, when you’re planning for your next sprint, you can easily look at the items in the backlog. You’ll understand what you need to accomplish and estimate what your team can handle. This enables us to say:
“Our goal is to deliver _________. To do so, we must deliver these _________ items. We have capacity for _________ amount of work. So we are going to do __________ in order to get there.”
From there, you can cherry-pick from your categorized items and pull them into the next sprint. We’ll go into further detail on how exactly to score these items and pull them into the sprint backlog below.
Step 2: Pull backlog items into sprint workload
Ultimately, your sprint backlog might look something like this:
This system provides the structure that your team needs to feel empowered. The more organized your backlog is, the better everyone feels; they know what’s coming and can actually move forward.
2. Arrange the top items on your product backlog to represent your next sprint.
One helpful step to organize your product backlog is to arrange the top portion of the list as the contents of your next sprint.
This way you aren’t constantly looking at the backlog and asking, “When will we get to this?” and “When can we start tackling that?”
Using this strategy, the top items on your backlog aren’t just “top priority” tasks with no internal dates associated with them—they also have a built-in timeline: your next sprint.
Of course, you’ll need a mechanism for determining what items should be included in your team’s next sprint, and we’ll discuss ideas for that below.
3. Don’t include any task lower than second-level priority on the backlog.
This is another simple, clean way of determining what makes it onto your backlog and what needs to go somewhere else (like a “Longer-term Tasks” file). Priority level two is a logical cutoff point for what makes it onto your backlog, and here’s why.
You’ve been in brainstorming meetings where the team jots down 20 viable product ideas on the whiteboard. Maybe you’ve even hosted these meetings. Obviously, you can’t execute on all 20 of those ideas, at least not in any near-term timeframe. So what do you do? You prioritize: Maybe you select the best two or four of those ideas and break them into stories, tasks, and plans your team can start working on.
As for everything else on that whiteboard, you’ll capture it, of course, but you can’t put it all on your backlog (or, even more unrealistically, on your roadmap). The product backlog needs to remain as lean and realistic as possible. It should contain the things on deck for your next sprint, and the second-level priority items you’ll get to within the next few months. And that’s it.
For tasks below level-two priority, we have another suggestion…
4. Create a separate list for all of those lower-priority (or longer-term) ideas and requests.
What’s great about creating a separate list for less-urgent product-related items is that it helps you keep your product backlog limited to those tasks that are truly urgent or of high strategic value. This means it keeps your product backlog itself more strategically valuable.
Product managers who simply toss every request, idea, and task onto the bottom of their product backlog—because they have no other trusted place to capture and store those items—make every future review and reassessment of their backlog more difficult. They also make it more likely that they will miss something important when they look over their backlog.\
Tweet This:
“Product managers who simply toss every request onto the bottom of their product backlog make every future review and reassessment of their backlog more difficult.”
So create other lists to capture your product-related ideas that don’t earn a spot on the backlog. This can be a “Great Ideas” file, and maybe a “Longer-Term Tasks” list.
5. Assign scores (or use some other quantifiable system) for determining each item’s overall value.
At ProductPlan, we’ve included a weighted scoring tool in our product roadmap app. We’ve found that when dealing with a finite amount of time, budget, and development resources, product managers need a mechanism to quantify (or “score”) the overall strategic value of each proposed feature or task against all of the others—to determine which will give their product the biggest strategic advantage.
But you can, and should, take a similar system to score the benefits and costs of items on your product backlog.
We recommend using a scoring model—whether based on ProductPlan’s suggested metrics including “Customer Value,” Increased Revenue” and “Implementation Costs,” or using some other system—to score each item competing for a slot on your backlog.
Some items will earn a spot in your short priority one list (planned for work in the next sprint). Others will make it to priority level two (planned for development in, say, the next three months). Everything else will find itself in your “Longer-Term Tasks” file. But when you’ve organized your list this way, you’ll know exactly why every item is where it is on your list. You’ll also be able to explain and defend your strategic thinking to your stakeholders and other teams.
6. Figure out a point system for assigning time and development resources to each item.
When prioritizing your backlog, one important factor to keep in mind for every task is how long it will take to complete. That means not only how many total developer hours but also which specific developers will need to work on the task, and for how long.
Then you might want to convert these hours (or days, or half-days) into points. Hammering out the code for a certain story, for example, might take a full day, which you might want to quantify as one point. This will make it easier to review items on your backlog against each other and calculate needed resources more uniformly across the list (as opposed to saying, “This item should take one developer a half-day, and this one will probably take two developers an hour each.”)
A word of warning: Remember to keep a task’s “big picture” in mind when trying to estimate how many hours (and whose hours) it will take to complete. For example, you might assume a bug fix is a half-point task—because, as you’ve set up your point system, one point equals one developer day of work. But while it’s true that identifying and correcting the bad code that created the bug might take just a half-day, completing that task will also require writing an automated test for the fix, and actually testing it. So you should be conservative in your time estimates—better to overestimate than underestimate the resources a task will take.
One more warning: Not all points will be interchangeable. It’s important to remember that your team is unique and has a unique set of skills, strengths, and weaknesses. This is why the backlog can play such an important role in your product and development teams’ planning sessions. Let’s say you have only one or two developers with the skill-set or experience to handle a story or feature. You need to budget the time (the “points”) of those developers carefully as you assign tasks for your upcoming sprint.
7. Re-evaluate the level one and two items on your backlog regularly.
Finally, it’s important to keep in mind that your product backlog is a living document—changing in priority often. After all, if you’re following the advice in this post, the top portion of your backlog should be disappearing after every sprint, as your team completes them. This means that some portion of the second-level items on the backlog will move up after every sprint as well, to the on-deck spot.
Read Jim Semick’s blog on Declaring Backlog Bankruptcy.
When you’ve followed all our suggestions, every item on your backlog now has a strategic reason for being exactly where it is on the list. You’ll find it much easier to review that list regularly. You’ll be able to determine if any new information—competitive intelligence, customer requests, or just a screaming-hot urgent fix—demands you reprioritize things.
Most importantly, you won’t be guessing with your prioritized product backlog. You’ll be making those prioritization decisions systematically.
Any other tips for successfully managing your team’s backlog? Share them in the comments below!
