Skip to content
← All terms

Glossary

What is request triage?

Request triage is the decision about what happens next to each incoming request, with four recorded exits: plan it, run a time-boxed discovery, park it with a review date, or decline it with a reason.

The test for real triage is that a request cannot leave the step still undecided. What most teams run instead is sorting — a weekly meeting that re-orders the queue, assigns labels and decides nothing, so the same items return every week. Deciding is faster than sorting: a recorded park or decline never comes back next week; a sorted item always does.

How to triage engineering requests

Take one request at a time and answer a single question: what happens to this next? Plan it, run a time-boxed discovery on it, park it with a review date and the condition that would revive it, or decline it with a reason the requester can read. Then move on. A request that leaves the step without one of those four attached has not been triaged.

Do it against the delivering teams' real capacity, not against an abstract sense of importance. Everything is important to whoever asked for it; what separates the four exits is whether there is room, whether the value is established, and whether anyone can own it.

Triage vs prioritisation vs sorting

Triage decides the exit for each request individually. Prioritisation orders the ones that survived, against capacity, for a given period. They are different steps and the second is worthless without the first — ranking a queue that contains work nobody would ever do just produces a well-ordered queue that nobody would ever do.

Sorting is what happens when neither is really being done: a weekly meeting that re-labels, re-orders and defers. Its output looks like progress and decides nothing, which is why the same twenty items are discussed every week and the oldest ones are the ones nobody is willing to refuse out loud.

Related terms

  • Backlog bankruptcy

    Backlog bankruptcy is the deliberate closure of an oversized backlog by finally making the decisions it contains — each item leaving as a recorded decline with a reason, a park with a review date, or a survivor someone will still argue for out loud.

  • Shaping

    Shaping turns a raw request into something decidable: the problem stated apart from the proposed solution, the intended outcome, what is known versus assumed versus unknown, and a likely owner.

  • Slow maybe

    A slow maybe is a request that is never refused and never advanced — kept alive by silence, costing the requester repeated follow-ups and the team repeated re-reading, until it dies unrecorded.

This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.