What percentage of engineering work actually ships?

Landed in Production divides the features that reached production by all features that were work in the window. A feature is an issue rolled up to the top of its parent chain, so work on a sub-task counts for its epic, and a feature counts as in production only when nothing beneath it is still unstarted.

Why does this widget count features when the widget next to it counts tasks?

This tile and the delivery funnel count features; every other figure on the Team Focus view counts issues. The two totals are not meant to match, and the Method & Caveats widget states both numbers explicitly so the difference reads as a grain, not a bug.

What does "merged but unshipped" mean?

Work that is finished on the engineering side but has not reached users — the waiting-to-ship stage. The boundary is the merge: in development is still the engineer’s to finish, waiting to ship is not. A large unshipped count is a release-cadence constraint, not a development one.

Are cancelled features counted?

Features cancelled before any work began are excluded from the population entirely, because they were never work — counting them either way would misdescribe the window. Features that were worked and then abandoned do appear, in the aborted-work stage.

What percentage of the work you built actually shipped?

Landed in Production is the ratio between work the team touched and work that reached users. It is the number that separates "engineering delivered" from "customers received", and the gap between those two is almost always a release problem rather than a development one.

deckgauge · Board · Team Focus

46%

of the work they touched shipped

17 of 37 features · 11 merged but unshipped

The tile, with the population it is over.

What it measures, and where the data comes from

The population is features, not issues. A feature is an issue rolled up to the top of the parent chain it hangs under, so a commit against a sub-task counts for the epic above it. Features are derived from the issues that were in the window, across Jira and Azure DevOps.

Each issue's raw board state maps to one of five delivery stages, and a feature's stage is rolled up from its children:

In production — shipped and reached users.
Waiting to ship — merged, not released. Finished engineering-side.
In development — still the engineer's to finish.
Aborted work — worked, then cancelled.
Not started / stalled — no work recorded, including states this board's stage map does not recognise.

Two grains on one pageThis tile and Where the Work Ended Up count features. Roadmap Focus, Never Moved, How Work Was Classified and Board Elements Worked On count issues. The totals are not meant to match, and Method & Caveats prints both so a reader is told rather than left to assume one widget is broken.

How the number is calculated

The roll-up rule is a strict precedence over the stages present among a feature's children, and the order is the whole rule:

Roll-up precedence

#	If any child is…	the feature is…
1	In development	In development
2	Waiting to ship	Waiting to ship
3	Not started / stalled	Not started / stalled
4	In production	In production
5	Aborted work	Aborted work

Applied to the set of stages present among a feature's children.

Two positions in that list are counter-intuitive and both are deliberate:

Active work wins. If anyone is building any part of a feature, the feature is in development — which is why an epic whose own status has not moved in months stops reading as idle.
In production ranks BELOW not started. A feature is in production only when nothing under it is still unstarted. Ranked the other way, one Done sub-task beat two To Do ones and the funnel called a feature landed while most of its scope had not begun.
Aborted work ranks last. A feature reads as abandoned only when every child was cancelled. One cut sub-task alongside live scope does not abandon the feature.

Worked example. Feature PLAT-40 has four children:

deckgauge · Every Task, and Why

Issue	Raw state	Delivery stage
PLAT-41	Released	In production
PLAT-42	Merged	Waiting to ship
PLAT-43	Done	In production
PLAT-44	Won't do	Aborted work

One feature's children, and the stage they roll up to.

Nothing is in development, so rule 1 does not fire. PLAT-42 is waiting to ship, so rule 2 does: PLAT-40 is waiting to ship, and contributes to the merged-but-unshipped figure rather than to the numerator — even though two of its four children are already in production.

Across a 37-feature window where 17 roll up to in production, the tile reads 17 ÷ 37 = 45.9%, printed as 46%.

Where this precedence loses somethingA feature with one shipped child and ten cancelled ones reads in production — something did ship. Those ten binned children leave the bar entirely, and their cost is reported separately as "days that went into aborted work inside features that shipped or are still live" on the delivery funnel. That second figure is the only reason losing them here is acceptable; read the two together or the waste is invisible.

How to read it

Read the percentage and the unshipped count as one statement. They decompose the same population into three groups: shipped, finished-but-not-released, and everything else. A 46% next to 11 unshipped says 76% of the work is at least engineering-complete — a very different picture from 46% next to 1 unshipped.

Do not compare this tile's total against the task counts elsewhere on the view. It says features on its face precisely because the tile beside it says tasks and means issues.

What it tells you over time

Watch the split between the shipped share and the unshipped count rather than the headline. Those two moving in opposite directions is the informative case: a falling shipped share with a rising unshipped count is a release bottleneck forming, and it is fixable by changing release cadence rather than by asking anyone to work differently.

A shipped share that falls while unshipped stays flat is the harder problem — work is not reaching engineering-complete at all, which sends you to the funnel's in-development and not-started bars.

Check the raw data Every number here is reproducible. Add Every Task, and Why — the ledger — to the same board and the same period. It lists every task with its raw state from Jira or Azure DevOps sitting beside the delivery stage it was mapped to, its class, the reason the classifier gave, its owner, its source system and its move count, and it filters by person, class and stage.

For this widget: set the Stage filter to In production to see the numerator, then Waiting to ship for the merged-but-unshipped count. The ledger lists ISSUES, so its row count is the larger, issue-grain population — expect more rows than this tile's feature total.

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. Engineering says done; customers have seen nothing

deckgauge · Landed in Production

22%

of the work they touched shipped

8 of 36 features · 21 merged but unshipped

Most of the work is engineering-complete and unreleased.

What you're seeing: 29 of 36 features are engineering-complete and only 8 have reached users. The team is not slow — the release pipeline is. This is the one shape on the Team Focus view that nobody on the development side can fix by working differently.

How to react: do not take this to the team as a delivery problem. It is a release-frequency problem, and the 21 unshipped features are inventory: work that has been paid for and is earning nothing.

Managerial playTreat the unshipped count as carrying cost and make it visible weekly, because it is the number that will keep growing quietly while everyone reports being on track. Find out what gates a release here — a manual QA pass, a change-approval board, a fixed release train, a single person who owns deploys — and time one end-to-end so the constraint is measured rather than assumed. Then either shorten the cycle or batch deliberately and say so, so the team stops accumulating finished work against a release date nobody has committed to. Recheck in a month: the shipped share should move, and if only the unshipped count moves you have found the real bottleneck rather than fixed it.

2. A healthy-looking ratio hiding abandoned scope

deckgauge · Team Focus

Figure	Value
Landed in production	61%
Merged but unshipped	4
Days in features abandoned entirely	96
Days in aborted work inside live features	143

A good ratio, read next to the funnel's waste figures.

What you're seeing: 61% shipped with only 4 unshipped is a genuinely healthy delivery ratio. But 239 days of attention went into work that was cancelled, and most of it — 143 days — was trimmed inside features that shipped, so those features count in the numerator and their binned scope appears nowhere in this tile. The ratio is not wrong; it is incomplete on its own.

How to react: this is a scoping and requirements signal, not a delivery one. Work that gets built and then cut was specified badly, prioritised badly, or overtaken by a decision made after it started.

Managerial playSample eight or ten of the cancelled items from the ledger and classify why each died — requirements changed, priority changed, it was speculative, or it was duplicated work. The distribution tells you which upstream process to fix, and it is usually one dominant cause rather than four even ones. Note that both waste figures are ALL-TIME rather than windowed, deliberately: the decision to cancel was made in this window, but the cost was paid across every window before it, so do not read a large number as this quarter's mistake. Report the shipped ratio and the waste figure together from now on — quoting 61% alone is accurate and still leaves the most expensive fact off the page.

Frequently asked

What percentage of engineering work actually ships?: Landed in Production divides the features that reached production by all features that were work in the window. A feature is an issue rolled up to the top of its parent chain, so work on a sub-task counts for its epic, and a feature counts as in production only when nothing beneath it is still unstarted.
Why does this widget count features when the widget next to it counts tasks?: This tile and the delivery funnel count features; every other figure on the Team Focus view counts issues. The two totals are not meant to match, and the Method & Caveats widget states both numbers explicitly so the difference reads as a grain, not a bug.
What does "merged but unshipped" mean?: Work that is finished on the engineering side but has not reached users — the waiting-to-ship stage. The boundary is the merge: in development is still the engineer’s to finish, waiting to ship is not. A large unshipped count is a release-cadence constraint, not a development one.
Are cancelled features counted?: Features cancelled before any work began are excluded from the population entirely, because they were never work — counting them either way would misdescribe the window. Features that were worked and then abandoned do appear, in the aborted-work stage.

Related widgets

Where the Work Ended Up — the same feature population, broken out across all five stages.
Person by Person — in-production and unshipped counts per person, at issue grain.
Method & Caveats — where the two grains on this page are reconciled.
Every Task, and Why — raw state beside mapped stage, row by row.
Method: Delivery stages.
Back to the widget reference.

Last updated 10 September 2026