Delivery funnel by stage: where the work actually ended up
Five bars covering every feature that was work in the window, from in production down to not started. Two of them are the ones nobody expects: aborted work, and the two figures underneath that price it.
| Stage | Features | Share |
|---|---|---|
| In production | 17 | 46% |
| Waiting to ship | 6 | 16% |
| In development | 9 | 24% |
| Aborted work | 3 | 8% |
| Not started / stalled | 2 | 5% |
The funnel, with the exclusions stated under it.
37 features — issues rolled up to the top-level item they hang under, so work on a sub-task counts for its epic.
What it measures, and where the data comes from
Each issue's raw board state from Jira or Azure DevOps maps to one of five stages via this board's stage map. Issues are then rolled up to features, and the feature's stage is decided by a strict precedence over the stages present among its children.
The stage vocabulary never appears in a query — the SQL returns raw rows and the meaning is applied afterwards, which is what allows the stage map to be edited per board without touching anything else.
How the number is calculated
Stage roll-up
The precedence order is the rule:
| # | If any child is… | the feature is… | Why |
|---|---|---|---|
| 1 | In development | In development | Active work wins — a feature is being built if anyone is building any part of it. |
| 2 | Waiting to ship | Waiting to ship | Merged beats shipped-in-part. |
| 3 | Not started / stalled | Not started / stalled | Ranks ABOVE in production: a feature is not landed while any of its scope has not begun. |
| 4 | In production | In production | Everything under it is done or cut. |
| 5 | Aborted work | Aborted work | Only when EVERY child was cancelled — the whole thing abandoned. |
First matching row wins, over the stages present among a feature's children.
Rules 3 and 5 both sit lower than a first reading would put them, and both were moved there after a board owner read the funnel and found it wrong:
- With in production above not started, one
Donesub-task beat twoTo Doones and the funnel reported a feature as landed while most of its scope had not begun — and the remaining work vanished from the page. - With aborted work above not started, a feature with one cut sub-task and one unstarted one rolled to cancelled, then took the never-worked exclusion below and told the reader it "was cancelled before any work began" — a feature that was never cancelled, still holding live scope, gone from the page entirely.
The population, and what is excluded from it
Features cancelled before any work began are excluded from the total and from every bar. They were never work, so counting them either way would misdescribe the window. The widget states the exclusion rather than applying it silently, and when it accounts for the entire population it says so instead of showing an empty funnel — "every one of the N features in this window was cancelled before any work began" is a process fact, and reporting it as an idle team would be wrong.
The two waste figures
These are separate on purpose, because they are two different problems that were previously being added together:
- Days in features abandoned entirely — a feature built and binned whole.
- Days in aborted work inside live features — scope trimmed inside a feature that shipped or is still live.
The second is also what keeps the roll-up precedence honest. A feature with one shipped child and ten cancelled ones reads in production, so those ten binned children leave the bars completely — and their cost appears only in this figure. Remove it and the precedence starts hiding waste.
Worked example
A window returns 40 features. Three were cancelled with no work ever recorded against them, so the population is 37. Of those, 17 roll up to in production, giving the in-production bar 17 ÷ 37 = 46%. The excluded three are named underneath rather than dropped.
How to read it
Check for an unmapped-state warning first. States this board's stage map does not know are counted as not started, which inflates that bar and empties the two middle ones — so an unmapped-state warning invalidates the shape of the whole funnel until it is fixed. The widget names the offending states and, for anyone with edit rights, offers the stage-map editor inline: the fix belongs next to the wrong number, not in a settings page nobody has a reason to open.
Then read the middle two bars as separate constraints. A fat waiting-to-ship bar is a release problem and no engineer can clear it. A fat in-development bar is either genuine work in flight or too much started at once — cross-check Never Moved to tell those apart.
Read the waste figures last and read them as sunk cost, not as this quarter's mistake. They are all-time by design.
What it tells you over time
The shape moves slowly, so a change in shape is meaningful. Mass migrating from in-development to waiting-to-ship without in-production growing is a release cadence that has stopped keeping up with development. The reverse — in-production growing while waiting-to-ship stays flat — is a healthy pipeline.
The aborted-work bar is the one to watch across windows rather than within one. Occasional cancellation is good hygiene; a bar that is consistently 15–20% of the population means work is being started before it is decided.
For this widget: the State column shows the raw value from Jira or Azure DevOps beside the Delivery stage it mapped to — so a bar you distrust traces to the exact states feeding it. Filter Stage to Not started / stalled first if the funnel warned about unmapped states; that is where they will all be sitting.
The raw state sits next to the mapped stage deliberately: that is what lets you see how a state was interpreted and argue with it, rather than being handed a stage and asked to trust it. See the ledger reference for the full column list, or Ledger & caveats for the method behind it.
Example situations
1. An unmapped state has broken the shape
| Stage | Features | Share |
|---|---|---|
| In production | 11 | 30% |
| Waiting to ship | 0 | 0% |
| In development | 2 | 5% |
| Aborted work | 1 | 3% |
| Not started / stalled | 23 | 62% |
Two middle bars empty, not-started inflated.
Counted as not started because this board's stage map does not know them: Ready for QA, Client review, Awaiting release.
What you're seeing: not a stalled team — a stage map that has never been configured for this board's workflow. Three real states are unrecognised, so every feature sitting in QA, client review or awaiting release has been dumped into not-started. Waiting-to-ship reads zero while Awaiting release is where the work actually is.
How to react: nothing about this funnel is readable until the map is fixed, and the fix is two minutes of work. Do not interpret the bars first.
Ready for QA and Client review are judgement calls worth making deliberately, because whether QA counts as in-development or waiting-to-ship changes who owns the queue. Decide it once, with the team, and write down the reasoning: the middle boundary is the merge, so the honest question is whether the engineer is still on the hook. Then re-read the funnel; expect not-started to collapse and the middle to fill, and treat the new shape as the first real reading this board has had.2. A healthy funnel with expensive waste underneath it
| Figure | Value |
|---|---|
| In production | 21 / 34 (62%) |
| Waiting to ship | 4 (12%) |
| Aborted work | 2 (6%) |
| Days in features abandoned entirely | 96 (all-time) |
| Days in aborted work inside live features | 143 (all-time) |
The bars look fine; the figures below them do not.
What you're seeing: a 62% in-production share and only two abandoned features — a good-looking funnel. Underneath it, 239 days of attention went into work that was cancelled, and 143 of those were trimmed inside features that shipped. Those 143 days appear in no bar at all, because their parent features correctly read as in production.
How to react: the funnel is not misleading you, but it is not sufficient on its own. The aborted-work bar counts features abandoned whole; the expensive half of the waste here is scope cut inside features that succeeded, and only the figure below the bars reports it.
Frequently asked
- What are the delivery stages?
- In production, waiting to ship, in development, aborted work, and not started or stalled. The boundary between in development and waiting to ship is the merge: in development is still the engineer’s to finish, waiting to ship is not.
- Why does a stage bar count features rather than tasks?
- The funnel and the shipped ratio count features — issues rolled up to the top-level item they hang under, so work on a sub-task counts for its epic. Every other figure on the Team Focus view counts issues, and the Method & Caveats widget prints both totals so the difference reads as a grain rather than a bug.
- Why are some figures marked all-time rather than for the window?
- The two wasted-day figures are deliberately all-time. The decision to cancel was made in this window, but the cost was paid across every window before it, so windowing them would understate what the cancellation actually cost.
- What happens to board states the stage map does not recognise?
- They count as not started, which inflates that bar and empties the two middle ones. The widget names the unrecognised states explicitly and offers the stage-map editor inline, because an exclusion nobody can see is indistinguishable from a bug.
Related widgets
- Landed in Production — the in-production bar as a headline ratio, over the same feature population.
- Never Moved — tells a genuine in-development bar from a stalled one.
- Method & Caveats — reconciles this widget's feature grain with the issue grain elsewhere.
- Every Task, and Why — raw state beside mapped stage.
- Method: Delivery stages.
- Back to the widget reference.
Last updated