What hospital triage can teach us about planning

Or, what I've learned listening to my wife.

It’s the day after planning. Your team has a carefully prioritized sprint - two weeks of work, neatly laid out and committed to! Except now a customer has escalated a bug and is already talking to the CFO about it. You hear whispers about needing a demo by Friday for the CEO. That neat priority list you had is now useless.

Compare this to an A&E¹ department where this is just a normal day.

Asking the right questions.

Triage systems are a prioritization framework based on clinical discriminators, not gut feel (the Manchester Triage System is a popular system). The key insight is it doesn’t ask “how important is this patient?”, instead asking “how long can this patient safely wait?”. Clinical need is prioritized on time sensitivity, not importance.

In software teams, our question is usually “how important is this?”, whereas a triage-informed approach asks “what’s the cost of delay curve for this work?”. Some P1 issues have flat cost-of-delay curves (critical but stable, like a patient with a broken arm). Some P2 issues have exponential curves (a small issue that will cascade if not addressed in the next two hours).

Why priority should change

In A&E, patients get reassessed at defined intervals. Conditions change!

In software, most teams treat sprint priorities as fixed once planning is complete. This is the sunk cost fallacy dressed up as process. We’ve committed so we must deliver! But… conditions change! A bug that was “standard” yesterday is now affecting 10x as many people. An urgent item that was going to take a few days now has a simple work around, and so on.

Re-triage isn’t chaos, poor planning or tactical (rather than strategic), it’s just acknowledging change. A&E doesn’t apologise for reassessing patients, and neither should your team.

Dedicated Capacity for different work types?

Modern A&E departments don’t run a single queue. They run parallel streams, each with dedicated staff and space. As an example, consider the introduction of minor injury units. Without them, that broken arm would be forever waiting until there wasn’t an emergency. This increases overall throughput and reduces average wait time across the system.

There are parallels in software. Small improvements, quick fixes and technical debt wait behind large features indefinitely. This creates developer frustration (small wins don’t happen), an accumulation of small issues that can compound into big problems and customers who feel ignored on minor issues.

Consider allocating capacity to address different work types.

One way I’ve used in the past is “Fix it Friday’s” where we had dedicated time to fix issues that annoyed us. Another technique is to make sure there’s plenty of slack in the system (avoid over commitment).

Making Decisions Fast

A triage nurse can make a high-stake decision in 3 minutes. They don’t (just!) do this through superior intuition, instead they do it through decision protocols. Chest pain → radiating to arm → Red! A protocol reduces the cognitive burden and allows junior staff to make decisions that would otherwise require senior judgement.

In comparison, an engineering team can argue about prioritizing X over Y for considerably longer than it would take to actually do X and Y. Instead, make a protocol!

The goal isn’t to remove judgement entirely but to handle the 80% of case that are easy, to free up time for the genuinely ambiguous cases and to allow engineers to self-triage incoming work without waiting for product.

Just remember, protocols work for common patterns. But sometimes, it might be Lupus.

An image to explicitly spell out the meme.

Boarding

Boarding is when the A&E department is full because the wards are full. Put simply there’s nowhere for anyone to go. People stuck in corridors and even in the ambulances outside. If this happens then at best it’s a poor experience, and at worst people die.

Hospitals respond to boarding by escalating it as a system-wide problem. They don’t tell A&E to work harder - they open discharge lounges, expedite ward rounds, bring in extra porters, and sometimes cancel elective procedures to free beds. The whole hospital responds because A&E boarding is a symptom of system-wide congestion, not an A&E failure.

Software has its own boarding problems. Work gets stuck in code review, waiting for deployment slots, blocked on approvals, or queued behind some shared infrastructure team. It sits in a holding state - consuming mental overhead, accumulating merge conflicts, blocking everything downstream.

When boarding happens, make it visible and treat it as a system problem. If code review is the bottleneck, that’s not a signal for the author to nag harder instead it’s a signal that the team needs to change how it allocates attention to reviews. If deployment queues are backing up, that’s not a release engineering problem, it’s a flow problem that affects everyone.

When Triage logic doesn’t make sense

A triage system optimizes for population outcomes, not individuals. An individual who might benefit from immediate attention might wait because others are more needy. Individuals might fall through the cracks and triage accepts this trade-off.

In software if we follow a strictly utilitarian prioritisation system then we might consistently deprioritise some flavours of work (such as dev experience, speculative innovation or niche features for important customers).

The point here isn’t that triage is wrong, it’s that you need to be explicit about the trade-offs you’re making and build in mechanisms to catch the cases that pure triage logic would miss.

Putting it all together

Don’t think about sprint planning as the optimal sequence of work. The goal is to build a triage system that can handle the inevitable chaos while maximising outcomes across the whole portfolio of work.

Sometimes the right triage decision is to stop working on the most important thing. If your most critical item is stable and can wait, but a less critical item is about to cascade into a major incident, the correct move is to switch. This feels wrong but is often right. Triage teaches us to optimise across the portfolio, not fixate on the top item.

1. A&E stands for “Accident and Emergency”, and apparently, it’s quite a UK specific term. For anyone else, mentally replace A&E with ER!