Backlog rank-ordering is a reflection of the honest order that project tasks should get done. By being honest with ourselves on what the process is for getting this work done, we can skip past endless debates, stop wasting time, and focus on getting as much value as possible delivered within our constraints of budget and schedule.

Let’s assume you were sailing on an idyllic cruise, but have just crashed your boat on a remote island. After the initial panic, you and your group have realized that there is a lot of preparation needed before you can weather out the storm that is approaching in the next day. You all agree on the four survival priorities as important: shelter, water, food, fire. But you have limited time to work and you disagree on which of the four are most important.

  • Is it fire, so you can keep warm, cook food, boil water, or make a signal for rescue?
  • Is it water, so that you don’t dehydrate trying to built a shelter and get rescued?
  • Is it food, so that you can keep your energy up as you work to protect yourselves?
  • Is it shelter, so that you can do all this work under cover, without rain soaking your clothes, making you cold, and possibly causing illness?


There are valid and convincing arguments for each of the four, but you only have a short time to prepare. Would you rather spend your time debating the merits of your argument with your compatriots, and only afterward decide how exactly you’re going to meet one of those priorities? Or would you rather get achievable things done first that deliver the most value, using your time as wisely and efficiently as possible?

Software companies end up in this scenario all the time. As the project schedule marches ever closer to the deadline, debates rage:

  • Is this bug a Priority 1 or Priority 2? Major or minor?
  • Can we cut this VP’s pet feature that is part of a larger “social” initiative in the company?
  • Do we add this bug to the official bug tracker, where project managers will see it and freak out, or do we maintain a separate list of bugs that management doesn’t need to know about?


All of these problems go away or are minimized with the introduction of two simple things:

  1. A rank-ordered backlog of tasks, where the first item delivers the most relative business value to stakeholders, and the last item delivers the least relative value.
  2. A product owner, or stakeholder, who is responsible for maintaining the order of items in that backlog.

You might ask: why not order by priority? All the P1 bugs have to get done anyway, so what difference does it make? Let’s return to the survival scenario. It is often the case where the single most important feature or need can be identified, but the remainder are up for debate. Assume that the shelter has been identified as the most important need, and focus on what it takes to build a shelter. To start, here is how the shelter work might be prioritized:

  1. Roof
  2. Walls
  3. Foundation
  4. Door

The roof is the most important aspect. It’s there to keep the rain off you, your clothes and food dry, and protect a fire from washing out. But, even though it’s the top priority, how are you going to build the roof first?

Now let’s look at a backlog ordering that reflects the way the work will actually be done, by delivering the most value up front:

  1. Foundation
  2. Walls
  3. Roof
  4. Door

You do the second task after the first task is done, the third task after the second is done, and the fourth task after the third is done. And now you have a usable shelter.

Software works the same way. You can’t build a working login screen until your back-end authentication is working. That’s just the reality of it.

So why spend unnecessary time and resources debating the minutiae of priorities? With a stakeholder (or, as is more common, a group of stakeholders) setting the backlog order, there should be no confusion as to what the team works on next.

If your company or client suffers from these problems, there are some easy steps you can take without necessitating an entire Agile transformation:

  1. Organize your work into a backlog. You likely already have a bug tracker and a feature tracker, and if you’re lucky, they’re in the same system. The point is to make an artifact for every piece of work you have, even if that means sticky notes on a wall or printing out a piece of paper for each task.
  2. Get someone to order it. In the absence of a truly involved business stakeholder, have your project manager do it. There’s definitely someone on your team who has the best understanding of the high-level business requirements. Encourage them to list out each task artifact in order. No ties or spot-sharing allowed. Bugs and features hold equal weight in a backlog, but it’s up to the person ordering it to determine where they fall in the ordered list.
  3. Do the work. Take the top item first, and work on it until it’s done. Then take the second item. Repeat until your stakeholders are satisfied with the product and you’ve met your deadlines.

Backlog rank-ordering is a reflection of reality and how the work is actually going to get done. By being honest with ourselves on what the process is actually for (to get the work done!), we can use it to our advantage. We can skip past the endless debates, stop wasting time on work that isn’t necessary, and focus on getting as much value as possible delivered within our constraints of budget and schedule. You’ll be much happier in your work, and the stakeholders and users will be happier with the resulting product.

Paul Gambill is project manager at Deloitte Digital. He also maintains his own personal blog, Medium, where you can follow more of his thoughts on project management and productivity.