GUIDE
Cancellation Rate: What It Measures and Why It Matters
The share of started work that gets abandoned instead of delivered — a scoping signal that most delivery metrics quietly ignore.
What it measures
Cancellation rate is the share of work items that get marked cancelled or abandoned instead of reaching a genuine "done" state, over a chosen period. It requires a workflow that tracks "cancelled" as its own distinct status — separate from "done" — since a tool that only distinguishes open from closed will quietly count abandoned work as delivered, the same failure mode that shows up in cost classification when cancelled work isn't tracked as its own category.
Why it matters
A high cancellation rate is rarely an execution problem — it's usually a scoping or planning one: work getting started before requirements are settled, priorities shifting mid-sprint, or a backlog that accumulates items nobody circles back to reconsider. Left untracked, cancelled work has a second, quieter cost: it inflates every other number that assumes "started" work eventually finishes. A team's velocity, cycle time, and even flow distribution all look different once abandoned work is separated out from work that was actually delivered.
How to calculate it
Divide the count of work items marked cancelled over the period by the total count of items that reached any terminal state (done or cancelled) in that same period.
A worked example: a team resolves 60 items in a month — 54 reach done, 6 get cancelled. The cancellation rate is 6 / 60 = 10%. Reported alongside velocity, this matters: a team that "completed" 54 items and cancelled 6 looks very different from one that reports 60 items "closed" with no distinction at all.
How to interpret the numbers
There's no published industry benchmark for an acceptable cancellation rate — some cancellation is healthy and expected, since it means a team is willing to kill work that no longer makes sense rather than finishing it out of sunk-cost momentum. What's worth watching is the trend and the reason behind it: a rate that's rising because of clearer, earlier prioritization is a good sign; one rising because requirements keep shifting after work already started is a planning problem worth naming.
A common trap
The most common failure isn't a high cancellation rate — it's an invisible one. A tool or workflow that doesn't have a genuine "cancelled" status forces cancelled work into "done" by default, which quietly overstates delivery and understates the real scoping problem. If cancellation rate looks suspiciously close to zero, the first thing worth checking isn't team discipline — it's whether the workflow even has a way to record cancellation as different from completion.
How moasy.tech computes it
moasy.tech tracks cancelled work as a genuine, distinct terminal state, separate from done, so it never silently inflates delivery totals. The same distinction feeds cost classification's CapEx/OpEx split, since abandoned work shouldn't count toward either bucket.
Back up to Team Health for the other signals in this cluster, or see how cancelled work is handled in the Cost Classification guide.
Questions about cancellation rate
Is a 0% cancellation rate a good sign?
Not necessarily — it can also mean the workflow has no way to distinguish cancelled work from done, which would hide a real scoping problem rather than solve it. Worth checking which case applies before treating zero as healthy.
Does cancelled work count toward velocity?
No — velocity counts items that reach genuine completion. Cancelled work is tracked separately so it doesn't inflate either delivery totals or the appearance of throughput.
Why isn't there a screenshot on this guide?
We only publish real product screenshots, never a mockup dressed up as one. This particular view isn't captured yet — this guide will get a real screenshot once it is, rather than an invented one in the meantime.