What is Delivery health?
A reading of whether a line of work is alive, taken from what actually shipped rather than from a status someone set by hand.
Self-reported status drifts; shipped work doesn’t.
On this page
Delivery health is a reading of whether a line of work is alive, derived from what actually shipped — merged changes, delivered tickets, landed work — rather than from a status anyone set by hand. It is the difference between asking "how is this going?" and receiving an adjective, and asking "what shipped last week?" and receiving a list.
The definition's engine is its second half. Self-reported status decays: a ticket marked "in progress" two weeks ago looks identical today whether it is about to land or has been quietly dead for ten days. Shipped work cannot be asserted — it either merged or it did not — which makes it the one signal that does not need to be trusted, only counted.
What it measures
A workable delivery health reading answers four questions, all countable:
| Question | Measured by | What it exposes |
|---|---|---|
| Is anything landing? | Delivery recency — when did work last ship on this line | Directions that are quietly dead |
| Is landing continuous? | Delivery cadence over recent weeks | Stop-and-start execution; burst-and-stall patterns |
| Does work survive review? | Bounce and rework rates | Briefs that are broken, review that rubber-stamps |
| Where is work waiting? | Age of what is parked at human gates | The bottleneck nobody owns |
Note what is absent: story points, percentage-complete bars, confidence emojis. Those measure the reporter; delivery health measures the work.
Why derived status beats reported status
Status fields fail in a specific, predictable way: updating them is unpaid work whose benefit accrues to other people. Every participant rationally lets them drift, and every consumer of the board learns — correctly — to distrust them. The drift is not a discipline problem; it is a design problem, and the fix is removing the human from the loop of recording while keeping them in the loop of deciding.
Derived signals have the opposite failure profile. They are computed from events that had to happen anyway — a merge is a merge, a review verdict is a verdict — so they cannot drift, only be misread. The craft is in reading them honestly:
- Silence is data. A direction with nothing shipped in three weeks is stalled, whatever its status says. The reading should say so, not soften it.
- Green with no deliveries is a smell. A line of work showing constant activity and no landings is either mid-build (fine, briefly) or churning (not fine) — and only the delivery record distinguishes them.
- Delivery is not the same as progress. A direction can ship constantly in the wrong direction. Delivery health says the line is alive; the direction's goal says whether alive means headed anywhere.
The organisational payoff
The point of the reading is not dashboards; it is where attention goes. Teams that trust derived delivery signals stop spending meetings extracting status from people and spend them on the readings that matter: which lines are stalled, which gates are accumulating waits, which briefs bounce more than they should. The 2024 DORA research programme's finding that higher AI adoption correlated with a measured drop in delivery stability is the cautionary version of the same principle — more output without a delivery-true feedback loop means less stability, not more — and you cannot manage stability you cannot see.
For agent-driven work specifically, the derived reading is the only scalable one: forty agents produce more work per day than any owner can supervise by watching, but every ticket still produces exactly one delivery event, and events are countable.
Delivery health in YATFA
YATFA derives delivery health from the transition record rather than from hand-set status: what shipped recently, per direction; how often review bounces work back; how long completed work waits at human gates. Directions that stop delivering surface as needing attention instead of hiding behind a stale status field. Owners read it, rather than compile it. See directions in YATFA.
Frequently asked questions
Isn't this just a burndown chart?
The shared idea is deriving status from events. The difference is scope and honesty: burndown tracks remaining estimate against time on one sprint; delivery health reads the actual delivery record — recency, cadence, bounces, gate waits — across every line of work, and deliberately refuses inputs someone typed by hand.
What is the minimal version for a small team?
Two questions and one rule. The questions: what shipped in the last two weeks, and where is the oldest thing waiting on a decision? The rule: never update a status field for the benefit of the board — if the board needs a field updated to tell the truth, fix the board.
Can delivery health be gamed?
Any measured thing can be gamed — that is a property of measurement, not a disqualification. The defence is measuring the things that are expensive to fake: shipping working reviewed code is a costly signal; updating a status field is nearly free. Health readings built on costly signals stay honest longer than incentives stay clever.