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.

Read the Product Manager's Guide to Prioritization  ➜

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:

backlog 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.
Download the Backlog Refinement: How to Prioritize What Matters Book➜
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!

Post Comments


  • Thomas Engdahl

    Most common error when using Jira (or similar tool) for storing good “ideas” is probaly that the list will be biased with ideas/request from developers and Product owners (actually having to tool ready at hand)

    This way it’s highly likely that ideas from other “non-operative” stake holders, such as top managment, sales, quality manager, security advisors, real end-users and support organisation will be forgotten.

    It’s the Product managers role to capture request from ALL stake holders , create forums and share and rpriritize ideas with all stake holders, this is better done in a separate tool.

    I often say, that the backlogg should only contain tasks/items we have decided to develop.

    • Shaun Juncal

      Hi Thomas,

      Thanks for you comment! I agree, and having a document or ideation portal for capturing all the ideas that aren’t quite ready for the backlog is important. It’s also important to have an impartial process for determining which items make it from that documents to the actual backlog.

  • Heather

    Wondering if you have a recommendation of the ‘long term backlog’? Is it an Excel spreadsheet or Word document? Should you break it up by functionality? Just looking for additional ideas!

    • Andre Theus

      Great question! In general, I don’t think the format matters too much. That said, between a spreadsheet and a Word document, I’d go with the spreadsheet. 🙂 But more importantly, all product managers need to know where the backlog lives and have access to it. That said, it can be challenging to send several documents around and keep everyone on the same page. That especially holds true to larger organizations. And that’s where online solutions like Atlassian Jira or Pivotal Tracker really become helpful. But again, the format is secondary in my opinion. It is more important to make sure you have 1) a prioritization framework as well as 2) a well-defined process on how to go through your backlog. Hope that helps!

  • ka

    Good article

  • Bill Whitson

    We found that another downside to having items in is that developers sometime would begin to look at things well in advance of when we were ready for them to. We leveraged Trello because it’s easy to maintain and we could Slack ideas directly in there. Once an item got fine tunes and vetted, THEN we would add it to our backlog in for ‘public consumption.’

  • Shaun Juncal

    Hi Bill,

    That’s a great point. Sometimes it’s not a good idea to grant full access to the backlog across your team. A lot of teams I’ve talked with have a sort of “two backlog” system: one for ideas and one for approved backlog items.

  • Sheri

    Regarding some of the comments about the long-term backlog and another comment above above about taking into account stakeholders’ requests/needs, we use Jira for both.

    We have a main Jira project for active development and short-term roadmap items (i.e. the backlog).

    A second Jira project for “enhancement requests” is the long-term backlog – we organize these so they are treated like high level epics and update them with relevant notes when required. The fields in the enhancement request tickets are structured to mimic epics, so we can easily move an enhancement request ticket into the active backlog when the time comes, and not lose any information associated with the request.

    A third project is used for “Intake” where we triage new stakeholder requests and move them into either the active or long-term backlogs.

    This allows us transparency and efficiency in our processes. Working under both scrum and Kanban methodologies, we don’t have concerns with developers working on items that haven’t been prioritized.

  • Shaun Juncal

    Thanks for sharing, Sheri! That’s super helpful, and I think it’s a good strategy for addressing some of the concerns people shared above.

  • Anonymous

    How do you actually prioritize? I was expecting to see the methods to do it – something like WSJF or CD3. Do you have any article that explains the actual method of prioritization?

  • Shaun Juncal


    We have written quite a bit on specific prioritization methods. Here are some additional resources:

    Have a great day!


  • Anonymous

    I’m not sure if I am 100% in agreement with this approach because I fail to see the real benefit. All viable requirements needs to be reviewed and dividing them won’t make the job easier. I prefer to use MoSCoW as a prioritizing technique. Obviously ‘W’ won’t ever make it onto the backlog with ‘S’ and ‘C’ being evaluated as part of the grooming process to possible move to ‘M’. Developers should not be looking at the backlog but rather the sprint log i.e. what they need to do to deliver the next sprint. The PO must take care of the backlog.

  • Calllum

    I would also highlight the danger of using weightings when calculating scores for priorities. Sometimes this can hide the actual valuable data that has been captured and can lead to errors in judgement. Kaplan and Norton summed it up well in their fourth book:

    “We often are asked how to weight the measures in a balanced scorecard. Such a question may be a sign that the organization does not truly understand the Balanced Scorecard management system. It is using the Balanced Scorecard narrowly for extrinsic motivation, by modifying its compensation plan, but has by-passed the more important strategy-setting and communication aspect of the Balanced Scorecard, which creates intrinsically motivated employees. Nevertheless, linking the scorecard to compensation is the time (and the only time) when weights do have to be created so that a multi-dimensional Balanced Scorecard can be reduced to cash, a single dimension.”

  • Tino

    Thanks for your good article.
    I have a question about considering a point to an item.
    For example, I want to build item A, How can I know about the required time for this item? that is a technical item so only a developer can assign a real-time to it.
    Could you please tell me about this?

Leave a Comment

Your email address will not be published.