Most people have seen this happen: almost every task suddenly becomes urgent.
You open the issue tracker and find five tasks, all marked high priority. The question comes immediately: which one should I start with?
You may panic for a moment, then pull yourself together and create your own order. Perhaps you pick the task you can finish fastest, complete it, and return to the list.
Now you have to choose again. That costs more attention and energy.
It gets worse when you start the next task and discover only after spending time on it that another task must be completed first. The time is gone, and there is nothing to show for it.
That is how a high-priority label stops helping and starts creating extra work.
I will use developers in the examples, but the problem is not specific to software. Give any team several equally urgent tasks with no clear order, and priorities stop working.
Priority inflation
This situation is often described as priority inflation. Too many tasks are declared important or urgent, so a high-priority label gradually loses its meaning.
If there are ten tasks in the queue and eight are marked High Priority, the label no longer helps a developer choose.
It answers the question:
Are these tasks important?
But it does not answer the far more useful one:
Which of them should I do first?
The developer still has to decide the actual order.
Sometimes the simplest task wins, sometimes the clearest one, and sometimes whichever one the manager mentioned most recently. The stakeholder who pushes hardest may sway the decision as well.
Priorities exist on paper, but the work still has no order.
Choosing the next task is work too
Looking at five tasks and picking one seems trivial, but that choice has to be repeated over and over.
You have to recall the context of each task, estimate the effort, identify its dependencies, compare the expected value, and decide what to take on.
That takes attention as well.
In Thinking, Fast and Slow, Daniel Kahneman describes deliberate thinking as something that requires effort and attention. The connection to task management is practical: every unnecessary priority decision consumes attention that could have gone into the work itself.
It is particularly odd to spend that attention on a question that in most cases should have been settled earlier:
What actually matters most to us right now?
A priority is also an order
Labels such as High, Medium, and Low are sometimes not enough on their own.
Say there are five tasks, all marked high priority.
The developer goes to the manager and asks:
Which of these really needs to be done first?
After the conversation it turns out that two tasks are critical and the other three are simply things it would be nice to get done soon.
The developer has enough capacity to complete three tasks.
The order then becomes clear:
- the first critical task;
- then the second;
- then the most important of the rest.
The other two carry over to the next cycle. At the next planning session, the team reviews them alongside new work and prioritizes again. That is normal practice.
A priority does not have to stay with a task forever. Today a task can be fifth in the queue and a week later be first because circumstances or business priorities have changed.
What matters is that at any given moment the team knows the order of work.
A similar problem appears at the strategy level. McKinsey describes a North American provider of financial and software services whose five-year strategy had grown to more than 25 priorities. Its leaders realized they could not manage so many priorities at once, let alone explain them all to employees, so the executive team chose no more than five strategic priorities for each year.
The scale is different, the principle is the same: a long list of important things does not yet tell you what to focus on now.
Dependencies have to be visible in advance
A single priority label is not enough for another reason: tasks can depend on each other.
The dependency may already be documented in the task description. But to discover it, the developer must first open the task, read it, and understand the context. Only then do they learn that the work cannot start yet.
Time has already been spent simply discovering the right order of work.
If a dependency is known in advance, show it in the issue tracker itself.
Dependencies should be surfaced during planning, before the task reaches a developer.
A ticket number on its own says nothing about the order of work. It is just an identifier.
Hope is not prioritization
Sometimes a manager sees five important tasks and marks all five as high priority.
The reasoning runs roughly like this:
Everything matters. Let us assign all five and hope they all get done.
That is not prioritization. It is handing the decision to the developer.
If a person can realistically finish three tasks out of five, the manager will have to answer this question anyway:
Which three do we want if the other two cannot be completed?
Better to answer it up front.
Otherwise someone can deliver three tasks flawlessly and then discover that the business was waiting for three different ones.
Urgency creates pressure
When everything is permanently marked High Priority, the developer feels perpetually behind.
One urgent task is a clear situation:
Put everything else aside and solve this.
Five urgent tasks at once send a different message:
You are already late on five important things.
No one can work on five tasks at once.
When that state becomes permanent, the label stops signaling urgency and turns into background noise. The constant feeling that everything is on fire and you are always behind can become another source of stress and burnout.
After time away, restore context first
Returning from a vacation or another long absence creates an additional problem.
The bad version goes something like this:
While you were away, we decided these three tasks were urgent. They are yours.
The person does not yet know what happened over the past two weeks, which decisions were made, why the priorities changed, or what new dependencies appeared.
Yet they may already be expected to deliver quickly.
They will need time either way—if not to do the task, then to rebuild the missing context.
Before assigning an urgent task after a long absence, take a few minutes to explain:
- what changed;
- why the task became important;
- what work has already been done;
- what it depends on;
- what result is needed now.
A few minutes of context can save hours of work in the wrong direction.
What to do about it
Restore a clear order
Start by reviewing the existing queue and giving the team a clear order for the near future. The manager and the people responsible for the product should decide which tasks must come first, which can wait, and which cannot start yet because of dependencies. If the first task is blocked, the team should already know which one comes next.
A useful priority should answer not only “how important is this?” but also “what do I do next?”.
These are the rules I would follow:
- do not mark every task as high priority;
- state the order of the genuinely important ones explicitly;
- account for the team’s real load and capacity;
- separate work into now, next, and backlog;
- show dependencies between tasks;
- set the order of subtasks inside a parent task;
- revisit priorities regularly;
- give context to anyone who was not part of the discussion;
- do not leave the final business-priority decision to the developer.
Even if every task is important, one of them still has to be done first. If the developer has to choose that order every time, prioritization did not happen; the decision was simply delegated.
Split the queue into three groups
A task that did not reach the front of the queue is not automatically unimportant. The team simply has not promised to work on it right now.
In practice, tasks can be split into three groups:
- Now: a short, explicitly ordered list that matches the team’s capacity;
- Next: the tasks the team will take after the current work is complete;
- Backlog: ideas and requests with no promised date that must still compete with new work.
This way, a stakeholder can see that their task has not been lost while understanding that it is not first in line. At the next planning session, the team reviews Next and Backlog alongside new work. Some tasks move up, some stay in the backlog, and stale ones can be closed.
Some work is repeatedly displaced by urgent product tasks: technical debt, dependency upgrades, and better tooling. If that work matters, reserve capacity for it instead of waiting for a free window that may never appear.
Set the order of subtasks
If a parent task represents one business outcome, assign the priority to the parent task. There is no need to mark every subtask as High Priority; that adds no useful information. If some steps can run in parallel, show that through the links between subtasks.
If one subtask blocks several parent tasks or delivers value on its own, pull it out into a separate task and link it to the work it unblocks. It can then have its own place in the shared queue.
Find the cause of the overload
Tidying up the list is not enough. The lead or manager should also determine where all the urgent work came from in the first place.
The company may have opened a new line of business while the team stayed the same size. Support demand may have grown, unplanned work may have appeared, or one business goal may have changed without anyone removing the old commitments. The same team is then expected to deliver more than the plan allowed for.
That gap between the volume of work and the team’s capacity has to be made visible to the business. Hiding it and covering it with overtime is dangerous.
In reports, this may even look like an efficiency gain and become a reason to praise the manager: the same team suddenly delivers more. But when the result depends on overtime, employees pay for that extra output with their own time and energy.
Some people can sustain that pace longer than others, but some will burn out or decide to leave.
Review the planning assumptions
Revisit the quarterly plan and goals, and answer a few questions honestly:
- Did we account for work that was not in the plan?
- Did we recognize that the new line of business would consume part of the team’s capacity?
- Did we remove old commitments when new ones arrived?
- Did we warn the business that the current team might not have enough capacity?
- Were we willing to speak openly about the risks and limits?
The point of that review is not to find someone to blame. It is to work out which assumption turned out to be wrong, agree on a realistic volume of work with the business, and avoid repeating the same situation next sprint.
The team deserves the truth about what is happening as well. If people regularly work overtime, pretending everything is on plan is not an option. It is more honest to revisit the deadlines, scope, or staffing and decide what genuinely has to come first.