What works for kanban prioritization on an actual board

Short answer: Kanban prioritization is deciding which card gets pulled next. Nothing more. For most teams: pick one framework (RICE, MoSCoW, or WSJF) by the question you're answering, use three priority categories at most (Expedite, Standard, Later), and prioritize the top of the queue rather than the whole backlog. Cost of delay is the only number that consistently produces good decisions. If your board is small enough to take in at a glance, you can skip prioritization meetings entirely. Just pull the next card.

The work of Kanban prioritization is deciding which card to pull into Doing from the board. That's all. One phrase. The rest of this post sees the light of day because many teams have successfully managed to turn one sentence into a several-day-long workshop using a colour-coded matrix and a Slack channel called #priority-discuss that no one reads.

If you’ve never been in a prioritization meeting where everyone parked on the same five “P1” tickets, congrats. The bug has been identified. Your board doesn't have this. It is in your priority model.

If you would rather write code than run another stand-up about which ticket is more urgent, this guide is for you. The four models worth bothering with, how to pick between them in five minutes, why three priority categories beats five every time, and one opinion that will get you uninvited from the next "alignment session": for most kanban teams, prioritizing the backlog is theatre. Prioritize the queue.

There is also an indication of when not to prioritize at all since the question nobody asks is whether the meeting is the right intervention at all.

Kanban prioritization, plainly explained

The practice of prioritizing Kanban cards entails arranging cards in your backlog and at the top of “To Do” such that the next card pulled is the most valuable one to pull right now. The most fundamental kanban rule is to pull from the top. Prioritisation is making sure what’s at the top is the right card.

What makes kanban prioritization different from sprint-based one is that there is no sprint boundary. You are not committing to a fixed batch every two weeks. You are maintaining a sorted queue that will always be ready to dispatch one card. It changes the question from “What’s in this sprint?” to “What’s the next card?”; which is a less momentous decision and is arguably easier to get right.

We define it in three parts.

• The queue is sorted, not the backlog. The top 5–10 cards are deliberately ordered. Cards further down don't need a precise ranking — they need to be in the right rough bucket.
• Priority decides pull order, not work order. A card with higher priority gets pulled sooner; it doesn't get worked faster. Trying to "speed up" a card in flight is what WIP limits exist to prevent.
• The unit of decision is the next card. Not "the roadmap". Not "the quarter". The next card. If you can answer "what should we pull next?" you've prioritized enough.

The popular meaning of prioritisation is “rank everything by importance, and then work in order”. That is not prioritization. This is sorting and the root of most teams’ 47-cards-tied-for-P1 problem. Genuine prioritization refers to identifying the next card to yield maximum value. The question is much narrower than to rank the universe.

The four prioritization models worth knowing

Approximately 40 prioritization frameworks exist in what0s published literature. You should know a number of four. Any other methodology is just a re-skin of one of them with a different consultant attached.

The WSJF formula traces back to SAFe's Weighted Shortest Job First definition, which is worth a skim if you've only ever seen it second-hand on a slide deck.

Two Guidelines for Selection

• RICE is the model you reach for when you have a lot of ideas and want them ranked numerically. It's a calculator. It produces a sortable list. It's also the one that gets gamed hardest — engineers underestimate Reach, PMs overestimate Impact, everyone overestimates Confidence. Use it for first-pass ordering and don't take the absolute numbers seriously.
• MoSCoW is the model you reach for when the bottleneck is stakeholder politics, not math. "Must / Should / Could / Won't" gives you a vocabulary for negotiating with people who don't care about your spreadsheet. It also forces a "Won't" column, which is the actual point of the framework — get people to commit to not doing things.
• WSJF is the model you reach for when capacity is tight and the work types are mixed. It explicitly compares the cost of not doing something to the cost of doing it. This is the one to use when you're choosing between a feature, a piece of debt, and a bug. Atlassian's prioritization frameworks overview is a decent side-by-side if you want to see how teams pick between these in practice.
• Classes of Service is technically not a ranking model — it's a categorisation model. It tags cards as Expedite, Fixed-Date, Standard, or Intangible. You still need RICE/MoSCoW/WSJF to order cards within a class. CoS tells you which lane; the other three tell you the order in the lane.

Each team should have one model. When you combine the two workstreams it produces meetings that argue about the model instead of the work. A more detailed account of this can be found on LiteTracker prioritizing across the themes in your product. The principle is easily extended to kanban: one ordering signal, consistently applied, beats four signals, inconsistently applied.

RICE, MoSCoW, WSJF — pick the one that fits the question

There is no deeper meaning to the choice between RICE, MoSCoW and WSJF. This needs to be triaged and takes about 5 min.

Ask in Sequence.

• "Is this fight about politics?" → MoSCoW. The framework's job is alignment, not optimisation. If three stakeholders disagree about which features matter, RICE will not save you — the spreadsheet just becomes the new venue for the same fight. MoSCoW forces categorical commitments, which is what you actually need.
• "Is this fight about capacity?" → WSJF. When the team is at WIP and someone is asking why their request hasn't been pulled yet, WSJF gives you a defensible answer. Cost of delay ÷ job size is the most honest single number in agile.
• "Is this fight about which features to even consider?" → RICE. When the backlog is a flat list of 200 ideas and you need to get to a top 20 fast, RICE is the right blunt instrument.
• "Is this fight about whether to interrupt flow at all?" → Classes of Service. The answer "we have to do this now" is a Class-of-Service question, not a ranking question.

An example that has been completed. Last year, I anchored a team that had a "prioritization problem." But it wasn't. It was actually four problems in a trenchcoat. Sales wanted three features, engineering wanted to pay down some auth-system debt, two production bugs were open, and the CEO had a "small ask" for a dashboard. Combining all items through RICE produced a ranking that nobody believed, because the units weren't comparable. Using these approaches led to various decisions MoSCoW for sales features, WSJF for the bug vs debt decision, Classes of Service for the CEO ask (which got tagged Expedite, then unscheduled when the CEO learned what Expedite means). Identical backlog. Separate question for each item. Various models for each question.

If there’s a single heuristic to take away from this section, it’s this: stop ranking apples and oranges with one number. Choose the model based on the question. Utilize it. Keep going!

Three priority categories. Not five. Not seven.

A P0 is more important than a P1, and so on. Other have 7. I once worked with a team that had eleven priorities, including "P0-but-after-lunch".

Three is the right number. The rationale is.

• Expedite — pull this immediately, even if it breaks WIP. Production down, contractual deadline, regulatory. Rare. Should fit on one hand per quarter.
• Standard — the default. Everything that goes through the normal pull rules.
• Later — explicitly in the backlog and not being prioritized right now. Will be revisited at the next refinement.

Introducing a new fourth category "P2", "Medium", "Should-do" seems to add new nuances. It does not. It incorporates an inbox where tasks are placed to forget without a sound. The five-category systems ultimately condense to two in reality. The expedite category is distinguished from the everything else category. The sorting of the everything else category takes place using the last shout technique. Human beings possess the limitation that they cannot intuitively rank order more than three ordinal categories.

Having more than three priority levels for a team means they really don’t have priorities. You have different types of regrets.

The reason for this is that MoSCow gives you four buckets – Must / Should / Could / Won’t – and in practice most teams collapse Should and Could because the difference is not actionable. Be genuine about this. Either agree to it or don’t. Resolving things through compromise is a way to simply defer the question.

Open your board how many cards are currently tagged P0 or P1? Now ask yourself if they all genuinely need to bypass the WIP limit. It's almost certain the answer is no. The solution to this problem is to rename your top tier Expedite and require an actual cost of delay argument to use it. Observe the rapid decline in the P1 count.

Cost of delay is the only number that matters

Most prioritisation frameworks ask "how valuable is this feature?". That is the wrong question. The perfect question to ask is “how much does it cost to wait?”

The cost of delay (CoD) refers to the monetary value or loss per unit time at which a feature is not shipped. There are three elements that you can bake in that “value” alone doesn’t give you.

• Time-sensitivity. A feature worth $100,000 over a year is worth more to ship in Q1 than Q4 — but a value-only model treats them identically.
• Competitive risk. If a competitor ships first, the value of being second is materially lower. CoD reflects that.
• Compounding. Some features unlock other features. The CoD of an unlock is the sum of the locked features' CoD plus a discount.

Calculating the honest version of cost of delay is surprisingly really difficult. The version most teams typically employ is the dishonest version, the three-bucket estimate. It still aids.

All set. Three categories. A CoD spreadsheet is not essential. You must have a CoD reflex If a card comes up as part of the prioritization, ask a clarifying question: “what will it cost us to not ship this for two more weeks?” If the answer is “nothing material”, note this down as not Expedite. If "We lose a customer" is the answer, then you have your answer.

LiteTracker monitors “predictability over velocity”, for the same reason – see Predictability over velocity. The objective is output maximisation not. Through cost-of-delay reasoning, you can make commitments that you can actually keep without resorting to theatre.

Swimlanes, classes of service, and the "expedite" abuse

Swimlanes are the horizontal lines which cut across the board to physically separate the work type or priority classes. When done correctly, they accomplish visualizing the priority model. If executed poorly, these meetings can serve to conceal the shortcomings of the priority model. The Kanban Guides definition of classes of service is the cleanest reference for what each lane is actually supposed to do.

The prioritization kanban swimlane standard structure is three lanes.

• Expedite (top) — strict WIP limit of 1 per team. Pulled before anything else.
• Standard (middle) — the default workflow. Most cards live here.
• Fixed-date or class-of-service-specific (bottom) — work tied to an external deadline, capped explicitly.

Most kanban teams go wrong in Expedite lane. The lane is for work that truly can't wait (e.g. incident, regulatory deadline, contractual obligation). In reality, it becomes filled with what the loudest stakeholder requested most recently. In the past 30 days, how many cards have been in your Expedite lane? Count them. If your answer is greater than three then your Expedite is broken.

Fixing it is a bigger problem than finding problems. Impose a cost on Expedite. Once a card is shifted to Expedite, another task should get removed from the WIP. Returned to the queue, put on hold, delayed. The cost of expedite is visible to the person requesting it, usually enough to make them rethink their request. When a stakeholder witnesses the elimination of their pet feature due to the upgrade of another card to Expedite, the abusive behavior rate reduces by 50%. No one else teaches them; it is the system enforcing its own rules.

If you are new to swimlanes, LiteTracker has you covered; their write-up at how kanban integrates with tracker workflows covers the mechanics of setting up lanes, WIP limits and other rules that hold the model together.

Refinement: prioritize the queue, not the cards

The all-hands prioritization meeting to “let’s go through the whole backlog and rank it” is theatre. It creates a list of criteria that no one believes, because they have forgotten the criteria used on card 3 by card 47.

What actually works is continuous queue refinement: short frequent sessions that only ever prioritise the top of the backlog.

The regulations.

• Refine weekly, in 30 minutes or less. Long sessions produce worse decisions, not better. The marginal value of minute 31 onward is negative.
• Refine only the top. The next 10–15 cards need to be sorted carefully. Cards 16–200 need to be in the right category (Standard / Later / Icebox) and that's it. Ranking them precisely is wasted effort.
• Cards below the line don't get ranked. They get a category and a tag. If they become urgent, they get re-considered at the next refinement.
• The team votes; the anchor decides. A flat democracy of seven engineers ranking 50 stories produces a ranking that's the average of seven biases. That's not better than the average of one informed opinion. Vote to flag concerns; one person makes the call. (If you don't have an anchor, you have a different problem and you're going to want Grooming your backlog more than you want this post.)

This is the section that most teams overlook. The prioritization meeting itself feels like progress, so they keep it going, even though the output is a sorted list, which gets ignored almost immediately. The discipline consists of not ranking what you do not need to rank.

There has been a separate yet related discussion about how much is enough refinement LiteTracker has a piece on finding the right amount of backlog refinement about that and is worth the read when you have cut the meeting from two hours to thirty minutes.

When NOT to prioritize the backlog

In every conversation, about prioritization, the underlying question is whether a prioritization is needed? At times the true response is no. When the board is small enough that the next card is obvious to everyone at standup, you don’t need to framework. Application of WIP Limits

Three indicators that prioritization can be overlooked.

• The board has fewer than 20 cards total. At this size, the team can see the whole board, agree on what's next, and pull. A formal framework adds overhead without adding clarity.
• The work is all the same type. A team doing only bug fixes, or only inbound support tickets, or only one customer's features doesn't have a prioritization problem — they have a triage problem. Triage isn't ranking; it's "do you start now or not?"
• The bottleneck is not in the queue. If your team is finishing cards faster than you can refine them, your problem is the funnel of incoming work, not the order of the queue. Fix the funnel; the queue takes care of itself.

Agile coaching usually assumes that imposing more rigor will produce better outcomes. It doesn't make sense. Making decisions is costly: meeting & context-switching time, decision fatigue, & more! The expense is justified only when there is real contention for the queue. Most Kanban Teams Are Not Many are accommodating prioritization rituals they do not need.

Much of what we think of as ‘prioritisation debt’ is actually ‘scope debt’. The team is not bad at ranking; they have too many things being asked of them all at once. It’s not in the prioritization meeting; the fix is at the intake gate, i.e., saying no to half the requests so that they never hit the board. There is some related advice in Velocity is not the goal; the main point applies here too.

Frequently asked

What is kanban prioritization?

It is a disciplined process to organize cards on a kanban board in such a way that the next card pulled into work is the one most valuable to pull right now. To summarize: The next five to ten cards in the queue are selected scrupulously, while the remaining cards are disposed in broad buckets.

How do you prioritize a kanban backlog?

Choose one framework to use (RICE for ranking multiple features, MoSCoW for stakeholder alignment, WSJF for capacity-constrained tradeoffs), apply at most three priority categories (Expedite, Standard, Later), and refine the top of the queue weekly in 30 minutes max. Leave the entire backlog alone from ranking.

What's the best prioritization framework for kanban?

There is no one best We prefer using the RICE method for ranking our work and the MoSCoW strategy to achieve political buy-in. When capacity is tight, we use WSJF. Classes of Service help us distinguish expedited work. You must select the one which is suitable to that question for which you’re answering and not the one which is best for a blog post.

What are kanban classes of service?

A system that tags cards as Expedite (pull immediately, breaks WIP), Fixed-Date (must finish by a specific date), Standard (the default flow), or Intangible (internal/cleanup work). While classes of service determine the lane, it is important to have a ranking framework to rank tasks inside that lane.

How often should we refine the kanban backlog?

Every week for 30 minutes, if possible, focus only on the top 10–15 cards. The longer the meeting, the worse the decisions, as criteria drift.

Should the whole team prioritize, or one person?

Concerns are raised by the team, however one individual decides. She is the anchor, the PM, the tech lead. Consensus group ranking generates an average of biases that no one claims. Decisions made by a single owner can be audited and revised.

How do you handle "everything is P1"?

The issue at hand is not about our prioritization; it is about the design of the category. Reduce the priority levels to three namely: Expedite, Standard, and Later. Further, require a cost-of-delay argument to proceed with Expedite. Watch how the P1 count drops like a rock.

When should you NOT prioritize the kanban backlog?

If the board has fewer than twenty cards, all work is of the same type, or the bottleneck is elsewhere in the system (e.g.: intake, deployment, or review). Prioritizing is cost intensive, it doesn't offer enough ROI unless the queue is genuinely contested.

Still stuck

With a clear choice of framework, three categories, and a refinement meeting of no more than 30 minutes, you have likely captured most of the value of kanban prioritization. The tool you use is the last 10%.

If you want to work with software that already enforces behaviour like predictability-over-velocity, accepted-stories-only counting, and a queue-for-P1-that-we-don’t-let-you-rank-47-things-as, that’s what LiteTracker is there for. No fee and no time limitation on the free tier without upselling a “paid priority module”. If you find a better use for Trello and Slack, use them instead. We prefer you not to pay us for friction you lack.

Stop conducting the prioritization meeting until the prioritization meeting has somewhere useful to point in either case.