How to Prioritize When Everything Is Urgent

A payments team with a regulatory deadline starts its sprint. The audit fix is in. So is a sales escalation for a large customer, a follow-up from last week’s outage, a partner request with a date attached, and two production bugs discovered at the sprint review. Every item is labeled priority one. The team is not slow. The list is simply not telling the truth about what matters. This guide shows how to prioritize when everything is urgent, in three steps.

Why Everything Becomes Urgent

Three mechanisms usually work together:

Intake without triage. Work enters the sprint directly from whoever asks, with no test of what happens if it waits.

Overcommitment. When the team has more work in progress than it can finish, everything runs late, and everything late starts to feel urgent. The urgency is a symptom of the load.

Urgency inflation. If escalating gets work done faster, people learn to escalate. Requests start arriving pre-labeled urgent, the same way estimates arrive pre-labeled “quick”.

Behind all three, there is often an organizational cause: no shared ranking at the top. When two executives each consider their initiative the most important, and nobody above them has ranked the two, every team below receives conflicting “top priorities”. Engineering leads cannot fix that alone, but they can expose it by asking, in writing, for the conflicting priorities to be ranked by the person who owns both.

That is why a prioritization framework on its own rarely fixes an overloaded team. Frameworks order a list; they do not shorten it. Ordering eleven items for a team that can finish five changes which disappointments happen first, not how many. So the first job is to shrink the list, and the last job is to fix intake.

Step 1: Test Every Urgent Claim

One question separates real urgency from pressure: what measurably happens if this waits one week?

For genuinely urgent items, ask one more question: what would this displace? If it displaces nothing, take it. If it displaces lower-priority work, sequence it (step 3). If it would displace another must-do item, escalate with the trade-off visible, using the approach in how to say no to unrealistic requests.

It also helps to ask what outcome the item is meant to produce. A request with no measurable outcome may not deserve priority at all, a theme covered in delivering value vs shipping features.

Step 2: Classify With MoSCoW

MoSCoW comes from the DSDM agile framework and sorts work into four groups:

• Must have: without it, the delivery fails or is unlawful, unsafe, or pointless.
• Should have: important and painful to leave out, but there is a workaround.
• Could have: desirable, included if time allows.
• Won’t have this time: explicitly out of scope for this cycle, which says nothing about the idea’s long-term value.

Two details make it work. The Agile Business Consortium’s MoSCoW guidance recommends that Must Haves take up no more than about 60% of the effort in a cycle, leaving room for the unexpected. If your Must list fills the whole sprint, it is not a priority list; it is a hope. And the Won’t category has to be real. A soft “won’t” that quietly turns into “maybe” teaches requesters that the classification does not mean anything.

Step 3: Sequence With Weighted Shortest Job First

MoSCoW tells you what is in. It does not tell you the order. Weighted shortest job first (WSJF), as documented in the Scaled Agile Framework, divides each item’s cost of delay by its job size, so valuable, time-sensitive, quick work goes first. SAFe estimates cost of delay from three relative factors: business value, time criticality, and risk reduction or opportunity enablement. The same page quotes Don Reinertsen, whose work underpins the method: “If you only quantify one thing, quantify the Cost of Delay.”

One rule comes before any scoring: legal and regulatory obligations do not go into the ranking. A fix required by a fixed audit date, or a bug that is charging customers twice, is not traded against a sales request on economic grounds. Treat those as constraints and schedule them first. WSJF orders the work that can genuinely be traded.

Here is a scored example for the tradeable items, using the modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20) that SAFe teams commonly use for relative estimates. Each column is scored relative to the other items, with the smallest item in each column anchored at a low value:

The assumptions behind the scores, written down so anyone can challenge them:

• Alerting gap: little direct revenue (value 3), but the outage it missed could recur any day (time criticality 5), and closing it prevents a repeat of an undetected incident (risk reduction 13). Small job: two alerts and a runbook update (size 3).
• Sales export: a renewal is at risk (value 8), and the customer decides this month (time criticality 8). Little risk reduction (3). Medium job: a new endpoint plus permission checks (size 5).
• Partner API: moderate long-term value (5), no deadline (time criticality 2), little risk reduction (3), and the largest job (size 8).

The order that results (alerting first, then the export, then the partner work) surprises people who expected the revenue item to win. That is the method working: a small, risk-reducing job with high cost of delay should go first.

WSJF has known weaknesses. Relative scores are noisy, and they are easy to inflate: a requester who learns that time criticality drives the order will start describing everything as time-critical. It also ignores dependencies, so an item with a modest score that unblocks three others may deserve to move up. Score with the team, write down the assumptions as above, and check the final order against common sense before committing to it.

Worked Example: Six “Priority One” Items

Run the payments team’s list from the opening through all three steps:

Six “priority one” items become two Musts, two Shoulds, one Could, and one Won’t. The duplicate-charge bug, which arrived quietly at the sprint review, turns out to be more urgent than the loud sales escalation. The two Shoulds are then ordered with WSJF, and the partner request gets a date for when it will be considered instead of a vague “soon”. The requester for the cosmetic bug hears a clear answer, which is usually better received than silence.

Notice that nothing here required a meeting with all six requesters. The one-week question did most of the work, and it gave each requester a reason they could understand.

For Your Own Time: The Eisenhower Matrix

For personal workload rather than the team’s queue, the Eisenhower matrix is a quick filter: do what is urgent and important, schedule what is important but not urgent, delegate what is urgent but not important, and drop what is neither. It works poorly as a way to rank a whole team’s queue, because it assumes everyone already agrees on what is important, which is usually the very thing in dispute. That is why the cost-of-delay test comes first.

Where it works surprisingly well is with a single requester who sends everything as urgent. I once worked with an SEO lead who was struggling to hit his targets; he was at 58% of his goal and under real pressure. That pressure flowed straight to my development team: every request he sent was P1. Arguing about individual tickets was getting nowhere, so I stepped in, walked him through the Eisenhower matrix, and asked him to pass each request through the four quadrants before sending it. Surprisingly, the volume of “urgent” requests dropped significantly. The matrix did not rank our backlog. It gave him a way to separate his own urgency from his own importance before the work reached us, and that solved most of the problem at the source.

Prevent the Next Pile-Up

Triage clears this sprint. Intake rules keep the next one clear. Three rules make a large difference:

1. Cap urgent items. Allow at most three urgent items open at once. A fourth urgent request has to displace one of the three, and the requester chooses which. This makes the cost of urgency visible to the people creating it.
2. Put urgent claims in writing. Each one states its cost of delay, who is requesting it, and the date by which it stops being urgent. Requests that cannot fill in the first field rarely survive.
3. Take intake on a schedule. Hold a short weekly intake session and route hallway requests there, instead of editing the sprint whenever someone asks. This mirrors the change-control discipline in the PMBOK Guide: changes are assessed against the whole plan by its owner.

Then reduce the load that creates false urgency in the first place. Limit work in progress to what the team can finish, and break work into smaller pieces. DORA’s research on working in small batches links smaller changes to faster, more reliable delivery. Small items finish, and finished work stops generating follow-up urgency.

The start of a project is another prevention point. Assumptions, constraints, and a definition of done agreed upfront reduce surprises mid-flight; see how to run a project kickoff that sets engineers up to succeed.

When to Skip the Framework

During a real incident, such as production down or an active security event, incident response takes over and the incident commander decides the order. A team of three with a short list does not need scoring; an honest conversation at a whiteboard is enough. And when an executive has already decided the order, follow it, then spend your effort on what was displaced: make the consequences visible in writing and renegotiate those dates. Reopening a settled decision through a framework rarely changes it and costs trust.

FAQ

How do you prioritize when everything is urgent?

Shrink the list first by asking what measurably happens if each item waits a week. Classify what remains with MoSCoW, then sequence it with weighted shortest job first. If the list fills up again next sprint, the problem is intake, so cap urgent items and take requests on a schedule.

What is MoSCoW prioritization?

A method from the DSDM framework that sorts work into Must have, Should have, Could have, and Won’t have this time. DSDM guidance suggests keeping Must Haves to around 60% of the effort in a cycle. It only works if “Won’t have” is treated as a real decision.

What is WSJF?

Weighted shortest job first: a sequencing method that divides an item’s cost of delay by its job size, so valuable, time-sensitive, quick work goes first. SAFe estimates cost of delay from business value, time criticality, and risk reduction or opportunity enablement, using relative scores agreed by the team.

How do you stop everything from being urgent?

Cap the number of urgent items open at once, require each urgent request in writing with its cost of delay and an expiry date, and handle new requests at a scheduled intake session rather than in the hallway. Then limit work in progress and work in smaller batches so things finish.

Shrink First, Then Sort

To prioritize when everything is urgent, keep the order: test the claims, classify the survivors, sequence by economics, and then fix intake so the list stays short. A team that can name its three genuinely urgent items works faster and calmer than one juggling eleven. The companion guides in delivery and process cover what happens before and after: kickoffs that prevent surprises, and retros that fix the causes.

Last updated on 10 October 2026