Relative priority of tasks with equal priority in a Kanban System

Question

Let suppose that we have two tasks with equal priority (let's say both are set to High priority in Jira). But the work on one task was started a couple of weeks ago, and the work on the other task was started a few days ago. The first task is just going hard, maybe because of being blocked for some time or maybe because it's been returned back to development after testing, it doesn't matter.

As far as I'm aware, in Kanban we treat the older task as more important (both are set to High priority, but the older one has a relatively higher priority) because we strive to make our service fast. So how do we maintain this relative priorities (make them in visible, noticable on the board), so that the team always knows the relative priorities and tries to complete the older tasks first?

For example, in Jira there are dots on the issue showing how much time the issue has been in the column, but these dots get reset if we move the issue on the board forth and then back, which makes these dots not usable for tracking the time the issue has been worked on.

Answer 1

I would recommend against having tasks of equal priority. Use the order in which they appear on the Kanban board to indicate relative priority. This will help the team to avoid having to constantly re-evaluate priorities.

To answer your question: it is really a team discussion around which task makes more sense to concentrate on. However, it would be worth keeping in mind the Kanban principle of focusing on completing work and limiting work in progress. I would typically advise a team to work on the tasks that are high priority and that can be completed sooner.

Answer 2

There isn't any rule, the team decides on how they work and how to signal different things occurring.

As you mentioned, you can add dots on the issue for each day it stays on the board, you can use different colors for the issues you will want to pay more attention to, if you have a physical board you can you can tilt the card from this ■ to this ◆, and the most obvious choice is to just place the issues one on top of each other and the team works on and picks from the top (just like a backlog is ordered for example, and you pick from the top), etc.

Kanban says that you should limit work in progress, so if an issue is long lived in your board, that's a sign that something must be happening (maybe something is blocked or waiting, maybe a team member is having a hard time and others in the team aren't helping, sometimes it's a sign that people are loaded at full capacity each with their own tasks and everyone minds their own business instead of swarming to relieve pressure points, etc). Your team should find a way to solve it and clear it from the board to limit WIP and thus improve flow and increase throughput and value creation.

Answer 3

in Kanban we treat the older task as more important

Close, but not exactly. If those tasks are being developed in parallel - it's okay to finish the later task sooner. What JIT (aka Kanban) actually says:

• Once we started - we need to finish any given task as fast as possible (decrease Lead Time)
• The amount of work in-progress (started but haven't been released/used/sold) has to be as small as possible (decrease WIP aka Inventory Costs)

The problem that you stumbled upon isn't new - in the original book on Kanban Method it's considered the toughest of all problems. The root cause is that tasks differ in duration too much. In perfect JIT this shouldn't happen and that's the main reason why many people think that JIT can be used only for projects in maintenance phase (in reality this can easily be improved).

The reason it's considered a problem is: if tasks differ too much in duration - you can't set WIP/Buffer limits properly. Otherwise what would WIP limit=3 mean? Today it's 2 days worth of work, tomorrow it'll become a month. And it's too easy to start more work in ColumnB even though ColumnC is overloaded. Or vice versa - unjustifiably stall because the "limits" are reached.

The JIT-ways of fixing this:

• Try as much as possible not to start new tasks if there are in-progress tasks already. Sure you have your WIP limits - but those are upper limits, try not to reach them. Perfect number of tasks in a column is 1. Look for ways to let more people work on a single task.
• Team members should know that finishing old tasks is always of higher priority than starting new ones. You don't need any JIRA capabilities to support this - the rule should be clear to everyone on the team w/o any reminders.
• And only if you must work on multiple tasks in parallel - then you can start a new task. And as I mentioned before - it can be finished sooner and that's fine.

But you're right - if some task gets reopened it has to have higher priority than the newer task. This allows releasing a bigger chunk of work (almost finished task) faster - decreasing WIP effectively. But you won't be able to implement this in JIRA. I'm used to a workflow where QA notifies the developer that the task is reopened and that developer can switch to it. Alternatively - QAs simply need to know that reopening should always put the task at the top of TODO/in-progress column.

Answer 4

So you have a couple of good answers. But to answer your question precisely: real priority in Jira is the Rank. Items at the top of a column have a „higher priority“, (assuming the board is set up this way).

Answer 5

Swarm, Reclassify, or Swap While Respecting WIP Limits

As far as I'm aware, in Kanban we treat the older task as more important (both are set to High priority, but the older one has a relatively higher priority) because we strive to make our service fast.

This is not inherently true. In Kanban, you can have items with different priorities or classes. In your case, the items are unlikely to be the same priority (in the sense of being ordinally identical), but may certainly be in the same class of service. How you prioritize items within the same class is up to your organization's working agreements.

On a more practical level, your team needs to decide how they want to manage their work-in-progress (WIP) limits. If you have a task that is blocked, stuck, or otherwise not flowing, you have a limited number of choices:

1. Highlight the blocked task where it is (e.g. it remains WIP), making the blockage highly visible to the team and the organization, and then encourage the team to swarm over it, unblock it, refactor it, modify its scope, or whatever else is needed to get it flowing again.
2. Move it to a different (but appropriate) column or swim lane with free WIP where it can be acted upon within the system's WIP and class-of-service constraints.
3. Send it back to the backlog to be refined, re-prioritized, or discarded, freeing up a WIP slot for an item that better meets the Definition of Ready or that's otherwise more actionable.

A basic rule of thumb is that if everything is a top priority, then nothing is. Prioritizing by age in a queue is certainly an option, and may be appropriate in certain contexts, but it is almost never a value-driven option. The team should strive to optimize value for the whole process, rather than solely optimizing for lead time of atypical items.