How to Tell the Difference Between Rank-Order and Prioritization

Too many of my clients confuse two specific terms: rank order and prioritization. Too often, that means the team works on too many items at the same time. That leads to high WIP, low cycle time, and low throughput.

So here are some visuals and an explanation.

See the image labeled “Rank Order.” When we rank order work, we choose one #1 priority, one #2 priority, one #3 priority, and so on.

We only choose one item at each priority.

Yes, that word “priority” is part of the problem. More on that later.

Contrast that image and explanation with how many organizations create a “Prioritized List” of work:

This organization said, “We'll prioritize work, but we have too much work to really discriminate among each of the items at the High, Medium, and Low levels. So we'll leave it to the team (or the product leader) to decide when it's time for them to decide.”

That sounds like the team has autonomy, doesn't it?

Not so fast.

This team has three “High” priority items. Depending on how large each item is, that might be an entire quarter's worth of work. Next, the team has six “Medium” priority items. How long will that take? I have no idea.

Worse, the team has 12 “Low” priority items. That might as well be an infinite list.

Let's talk about “Priority” and what that means.

What Priority Means

When we say, “prioritize,” we are supposed to answer this question: “What is the precedence of this item compared to all other items?”

When we rank work, with one item at each rank, we can tell.

But when we bucket work with High, Medium, and Low, we have only started to rank the work. If we allow multiple items at each rank (as I see in my clients), we have not finished the prioritization. Worse, some techniques for deciding which work to do now, such as MoSCoW, make it even worse. (MoSCoW means: Must, Should, Could, Would.)

When we prioritize several items at a time, we can end up in a very bad place with way too much WIP.

Years ago, one of my clients started with High, Medium, and Low. But High wasn't high enough, so they added “Really High.” Then, “Ultra High.” Yes, they started to use “Mega High” when I arrived.

The managers did this because the team had so much WIP that their throughput was quite low. See the Flow Metrics newsletter.

I asked all the managers to silently create a ranked listing of all these highs with a single list of index cards on the table. They could not agree. I gave them three minutes, and when Buzz disagreed with Woody for the third time, I stopped them. We discussed the problem, and I introduced them to ranking.

They could all agree on the top three items in their way-too-long list. That was good enough for the team to start work and start delivering. They need to rank work, not prioritize it.

Rank Work

Some of my agile colleagues recommend that a team can start bucketing work into High, Medium, and Low. But is that worth the time when so few teams ever get to Medium and Low? (Or any of the other prioritization terms?)

Worse, the product leader or the team does not really have the ability to say, “No” to any of the work. That means the team does not have the autonomy to decide.

That's why I recommend the team rank the work. You can either use cycle time or count the number of stories your team typically completes in a sprint. Only rank—and plan—for those number of stories. Then, the team knows what it's supposed to do now. That allows the product leader to pare down the options for the next bit of work.

I wish Ranking and Prioritization meant the same thing. Too many organizations do not treat those two activities the same way. Instead, rank the work with one #1  item, one #2 item, and so on. That will allow you to limit the WIP and finish the work.