The Best and Easiest Way To Prioritize Your Backlog

The Problem

One of the responsibilities of the Product Owner on a Scrum team is to make sure that the best value is delivered for the development resources spent. This determination drives the prioritization of the backlog and rarely is it done in a vacuum, that almost always there are business stakeholders providing the input that the Product Owner has to take into account when determining priorities. It is further complicated when there is a team of Product Owners that have to come to an agreement, and even worse if there is no clearly define Chief Product Owner.

Keep in mind time spent prioritizing and re-prioritizing your backlog adds no value to the product. It is waste and it the words of Taiichi Ohno, waste comes out of profit.

How Bad It Can Be

Over the years I have seen or been aware of various companies struggling with how to prioritize the work to be done by Scrum teams. Imagine a dozen mid to high-level managers flying to one office and spending the better part of a week going over a backlog containing several hundred items. Not only is the very expensive to the company in salary and travel, but there is also the opportunity cost when these people could be doing something else. This is also contrary to the spirit of Agile because things will probably change within a couple of sprints anyway.

Additionally whatever convention is used to indicate priority will quickly breakdown. Some examples are everything was give a ranking of 1-10 with 10 being the highest. However there were too many 10’s, so what do you do? You make some 11 of course. Another try was to rank things as High, Medium & Low. Since everyone knew no low’s would ever get done most things were a high. Again too many items are a H (high) so next go with H1, H2 & H3. Still far too many items were raked H1 to have any meaning.

A Solution

Something I have found that works is to not try and rank by importance but rather to do an order ranking. What should the team do now, next and then after that. You only need to know 3 things that are the top items at this point in time. The current item is what the team is working on and the stories are fully groomed and the UX work has been done. The item that is, to use a sports analogy, “on deck” UX can be working on and the 3rd item the Product Owner can be working on requirements gathering story writing & refinement. Of course, this cannot be a hard and fast rule as some things have a longer lead time than others.

The key is I don’t need to know today the priority of things that I and the scrum team will not be working on in the near future. I just need an ordered list of the next 3-5 items the team will work on. The Product Owner can review with the business stakeholders every sprint to add an item to the list of near future things to work on and make sure the list has not changed.

A Time To Lock-In

Try very hard to not interrupt work on an item once it has been started on by the development team and if possible also the items that the UX work has been done. My rule has always been once an item is in a sprint we finish it. There will be times that there are extenuating circumstances, but that should be the exception and not the rule.


This article is really talking about feature level items, not bugs or other minor fixes. This is something that will take most of the team most of a sprint or maybe two. I always try to have some small tasks that are important ready to go so when a team gets the sprint goal done they have some filler tasks to finish out the sprint. This is a way you can get bugs fixed or address technical debt. The key is they have to be very small items that you as Product Owner include based on your own judgment.

Why It Works

Rather than having hours worth of meetings to give everything a priority, just give the business stakeholders a homework assignment to go off and pick the next three things for the team to work on. You avoid all the talk and debate about is this a 9 or a 10 (we will make it a 9.5) and just have to pick what the business wants the team to do in the next couple of sprints. Trust me I have saved so much time since I went to this method.