Let’s talk tactics. How do you maintain your product backlog today?

If you’re like most product managers (read: busy!), you probably don’t have much choice but to 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.

6 Tips to Prioritize Your Product Backlog

1. Arrange the top items on your 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.

2. 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…

3. 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. Which 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—such as a “Great Ideas” file, and maybe a “Longer-Term Tasks” list.

4. 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 scoring 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), and 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, and you’ll be able to explain and defend your strategic thinking to your stakeholders and other teams.

5. 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—and 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. If you know you have only one or two developers who have the skillset or experience to handle a certain story or feature, you need to budget the time (the “points”) of those developers carefully as you assign other tasks for your upcoming sprint.

6. 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 be moving up after every sprint as well, to the on-deck spot.

When you’ve followed the other suggestions we’ve offered here, and 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 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. 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

11 Comments

  • Thomas Engdahl
    March 28, 2018 at 12:10 pm

    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
      March 28, 2018 at 1:39 pm

      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
    April 5, 2018 at 1:39 pm

    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
      April 5, 2018 at 1:51 pm

      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
    May 3, 2018 at 1:26 pm

    Good article

  • Bill Whitson
    August 16, 2018 at 2:14 pm

    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
    August 16, 2018 at 2:20 pm

    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
    January 11, 2019 at 3:37 pm

    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
    January 11, 2019 at 3:43 pm

    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
    March 16, 2019 at 12:08 pm

    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
    March 18, 2019 at 8:44 am

    Hello,

    We have written quite a bit on specific prioritization methods. Here are some additional resources:
    https://www.productplan.com/strategies-prioritize-product-features/
    https://www.productplan.com/lp/prioritization-guide/

    Have a great day!

    Shaun

Leave a Comment

Your email address will not be published.