The Best Way to Prioritize a Backlog is “Picking”

Pick. Don’t prioritize. If you think you need to prioritize your backlog, you most probably don’t. But if you can’t avoid it try this effective approach and save you and your team time and energy along the way.

8 min readMar 5, 2020

One question I frequently receive from teams, from product owners, and also from (executive) managers is the question: “How do we prioritize our work properly?”. In this post, I want to briefly indicate what seems to be the best way to prioritize a backlog in product development and knowledge work. If you don’t want to read my train of thoughts but are only looking for the answer to that question above jump right to my agile team’s FAQ to simply find my suggested answer.

How do we prioritize our backlog? This is an interesting question. Usually, I tend to answer like a real agile coach by asking a question back (haha!):‌ “Why do you need to prioritize?” Yeah, I know this sounds like an odd question, almost stupid. So stupid that you wouldn’t even bother to answer. However, the answer is relevant. Like in so many other instances the common practice is not the same as common sense would emphasize.

Common sense vs. common practice

Common sense might sound something like “We prioritize to figure out what is the best thing to deliver now.” This sounds very reasonable. It implies that the team can deliver now — meaning it has the capacity to deliver. Common practice more often than not seems to be that prioritization is simply a ritual. Backlogs are prioritized over and over again with an awful lot of effort to figure out the right order of the (often many)‌ backlog items without having the capacity to start new work. With that practice, teams come up with an order of work that oftentimes will never be started. Instead of asking the question: “What might be the right thing to do now?”, unnoticed teams slip into answering a different question:‌ “When will it be started?”. I know that this might be a pressing question in many organizations but it nevertheless is an irrelevant question when it comes to prioritization (find here why).

“Prioritization should be done only at the time of commitment.” Steve Tendon *

So before thinking about doing prioritization right consider if prioritization is the right thing to do at all. Odds are good, you don’t have to worry about prioritization.

It’s not to prioritize, it’s to pick

Photo by 🇨🇭 Claudio Schwarz | @purzlbaum on Unsplash

Ok. Let’s assume one team (and all the teams along the chain of dependencies)‌ has (have) the capacity to start something new and bring it to an end in one fell swoop. Now it’s time to pick what to deliver. I deliberately use the word ‘pick’ instead of ‘prioritize’. While in its original meaning priority described that one thing is ‘prior’ to anything else, it’s now commonly (mis-) understood as bringing a long list of ‘ideas’ into an order. Since this wasteful activity is not what we are aiming for, what to do instead?‌

There is an overwhelming amount of methods, techniques, and tools out there that claim to answer the question “what to pick next?”. I myself added a technique to the body of knowledge some years ago. No wonder product owners are almost paralyzed. It seems that there is a tendency in the agile community to become more and more sophisticated, analytical or mathematical about this topic. This is troublesome. It blurs the simple fact that all we are looking for is a simple decision: What work do we start now? The more sophisticated a method gets the more it implicitly claims to take off the burden of decision making from the people in charge. Especially in a more corporate environment, where certainty is king and doing everything right and according to a procedure is demanded, product owners desperately seek for some kind of formula that magically produces the decision (for them).

All of the methods, tools, and techniques, nonetheless have one major flaw in common. They all are based on hazy assumptions. In their (mostly mathematical)‌ rigor, however, they disguise this inherent uncertainty that comes along with assumptions. The more precise the mathematical procedure the more reliable the outcome of that procedure appears. But the outcomes are as unreliable as their underlying assumptions.

To be more specific, the procedures usually are based on assumptions of three kinds:‌

Expected impact of the work done. This impact often is expressed monetarily (like ROI, Cost of Delay, revenue per user, …).
The effort some kind of work is going to consume. This is generally expressed in terms of capacity or cost (person-days, hours, …).
The duration from start to finish. This tries to anticipate when the impact will materialize. This is generally expressed in days or weeks (lead time, cycle time, flow time, …).

To produce a sound calculation, teams have to input sound assumptions. Humans are optimistic creatures and they devise those assumptions. This generates a lot of non-value adding busy-work to come up with the input data for those calculations (often whole business cases are elaborated for relatively minor features). Sometimes non-product agendas also creep into this process and teams have to come up with a calculation that supports the implicitly expected order of features. And no matter how much work teams put into those assumptions they still will be wrong. In a high-uncertainty environment, you cannot know upfront what is going to happen. Building iteratively is the only option teams have to gradually develop an understanding and thus a better foundation for decisions. (Daniel Vacanti created a great piece on that symptom investigating the cost of delay calculation as a way to prioritize.)

I think in the realm of product development and knowledge work (where I come from), the way we handle prioritization is completely over-engineered. While there is no doubt about the mathematical correctness of the procedures, in an environment of very high uncertainty the assumptions feeding those procedures cannot be accurate enough to justify the work that teams put into. I think we spend way too much time on globe reading. All the fuss about the right prioritization method conceals the dirty secret that you can never know with certainty what is the right next thing to do.

But what to do instead?

“Fine”, you might think, “if all that is true, then what am I supposed to do as a product owner?‌ Somehow I have to decide on what to start next.” The answer is (…drum roll…): Do the tiniest thing of value first (tada!).

Please hear me out, this is not as stupid as it may sound. Always picking the tiniest work item of value from the backlog first has five positive effects:‌

Since this is (right after random selection) the easiest way to prioritize (meaning to pick the next work item) it makes teams self-effective. No lengthy discussions on arbitrary value expectations anymore. No manipulating spreadsheets to get the ‘right’‌ order. This prioritization approach is straight forward, easy to understand and quick to execute. This frees mental capacity and eliminates large quantities of busy-work.
It is by far more easy to anticipate the impact, effort, and duration of work items if those items are small. And although you don’t need those ‘values’ for the actual prioritization anymore they help to establish trust in the delivery capabilities of a team. And that is of tremendous value.
Over time everyone around that team will have learned that small is beautiful. This creates a working environment where people start breaking down big chunks of work into smaller pieces. And this is always a very good practice when it comes to risk mitigation and flow. This does not mean that you only do worthless micro-work. I have experienced that people are very well capable of breaking work down in small pieces while still keeping the overarching goal in sight.
Small work items deliver (business) value sooner. This accelerates learning and thus strengthens the capability of a team to (intuitively)‌ know in which direction to head over a longer course of time. Over time this effect gets linked closely with the first effect since the team can decide ever faster what to deliver next.
The urge to pick exactly the right work item next is reduced drastically if you pick tiny items. The team will make the wrong choice eventually. The selected work item will not generate the anticipated value. That is the same with big bets. But with tiny work items, the team learns fast and is certainly going to make a better decision next time.

Summary

Long story short, the best way to prioritize is to avoid it. Only prioritize when you can deliver the started work item in one fell swoop from start to end. This includes taking all the dependencies into account. Done means done!‌ If you don’t have the capacity to start new work, don’t waste what you don’t have on prioritization. As soon as you can start work pick, don’t prioritize! Pick the tiniest work item of value from the backlog and deliver it. Only after you are done, pick the next work item that is by the time of the decision the tiniest thing of value in your backlog.

This is easy, fast and fun. And it generates a lot of healthy side-effects as described above.

That’s the only reasonable way to prioritize product development work where uncertainty is your everyday companion.

Underlying Assumptions

I consider this approach perfectly suited for product development work in an environment that is complex and thus very uncertain. In that environment predictions of the future by definition cannot be made accurately.
This approach is suited for small cross-functional teams with little dependencies to deliver work of value (for the user and the business).
This works well in a work environment where teams know what is expected of them and what their overarching goal or their purpose of existence is. This may be supported by a goal system (like OKRs) or by very close contact with the real users.

On my account

Feel free to follow me on Twitter or LinkedIn to regularly receive excerpts of related content.