Haven't taken the check yet? Do that first — 14 questions, about four minutes. It scores you on the three areas below and tells you which one to fix first. Already have your result? Jump to your weakest area: Agile in practice · Delivery flow · Outcome ownership.

01The model

Three things decide whether work actually ships. A strong one can't cover for a weak one: great practice with broken flow still can't commit to a date; great flow with no ownership ships the wrong thing well.

01Agile in practice — an increment every sprint, retros that change things, a PO who prioritises.
02Delivery flow — work moving predictably from idea to shipped — WIP under control, releases boring.
03Outcome ownership — "done" means in users’ hands, and someone owns whether it delivered value.

The check scores each and gives a combined grade. The engagement, in a sentence: find the weak one and fix it first.

02Agile in practice

Practice is whether the ceremonies produce anything. The test: does every sprint end with something a user could actually use — not "nearly" — and does the retro change something the team can feel?

What good looks like
  • Every sprint ends with something usably done — not “nearly”.
  • Retrospectives produce change the team actually feels.
  • A product owner who owns the roadmap and can say no.
  • Mid-sprint change is renegotiated deliberately, not silently absorbed.
  • Estimates are forecasts you track, not promises people get held to.
Common failure
  • Velocity theatre — the number goes up; nothing ships faster.
  • Retro amnesia — the same issues raised every fortnight, nothing changes.
  • PO in name only — priorities set by whoever escalated hardest.
Your first move
If you're just starting

Make "usably done every sprint" the non-negotiable, give the PO real authority to prioritise, and use the retro to fix one systemic thing at a time. Certification-style training helps the vocabulary; the habit comes from doing it.

If it's partly there

The ceremonies run — now make them mean something. Tighten the definition of done, hold the line on mid-sprint changes (renegotiate, don't absorb), and shift estimates from promises to tracked forecasts.

If it's already strong

Protect it: keep the PO's mandate real as stakeholders multiply, keep retros producing change, and don't let "forecast" quietly slide back to "commitment".

Go deeper

  • Write the definition of done as a checklist the team authored — and block anything that doesn't meet it from being called done.
  • Give the retro one action with an owner and a date, and review it first thing next retro. One that lands beats five that don't.
  • Track estimates against actuals for a few sprints, out loud, so “forecast” becomes a number people trust rather than a stick.

03Delivery flow

Flow is whether work moves predictably from idea to shipped. Predictable, not faster — the goal is being able to give a stakeholder a date and usually be right.

What good looks like
  • You know your cycle time — idea to shipped — and act on the outliers.
  • Work in progress is limited, and the limit is respected.
  • Releases are boring. You ship on demand, not on an event.
  • Cross-team dependencies are managed early, or designed out.
  • You can give a stakeholder a date — and you're usually right.
Common failure
  • WIP overload — everything started, little finished, constant context-switching.
  • Hero releases — every deploy is an all-hands event.
  • “Done” that isn’t — dev-complete work piling up behind a release.
Your first move
If you're just starting

You can't manage what you can't see. Start measuring cycle time, cap work in progress, and make releasing routine rather than an event. Predictability comes from limiting flow, not from working faster.

If it's partly there

Flow is improving but still lumpy. Enforce the WIP limit, manage cross-team dependencies before they bite, and get releases boring. Then you can give stakeholders dates you'll actually hit.

If it's already strong

Keep the metrics live, keep designing dependencies out of the work, and watch for WIP creeping back up as demand grows.

Go deeper

  • Put a WIP limit on the board columns and hold it for two sprints — the discomfort is the point; finishing beats starting.
  • Chart cycle time per item and talk about the slowest 10% every retro: what made those slow, not who.
  • Shrink release batch size until deploying is dull. Small and frequent removes the all-hands drama.

04Outcome ownership

Ownership is whether "done" means value in users' hands and someone is on the hook for whether it delivered. Dev-complete work that sits is inventory, not value.

What good looks like
  • Dev-complete work that sits is inventory, not value. Done means in users' hands.
  • A named owner for the outcome — with the mandate to change course.
  • You measure whether shipped work delivered what it was meant to.
  • When delivery slips, the first move is look at the system — not the people.
Common failure
  • “Done” means merged — nobody checks whether it reached users or worked.
  • No outcome owner — accountability stops at the ticket.
  • Blame on slippage — “work harder” instead of “look at the system”.
Your first move
If you're just starting

Close the gap between "done" and "shipped" — dev-complete work that sits is inventory. Name an owner for the outcome of each significant piece, and start measuring whether shipped work did what it was meant to.

If it's partly there

Outcomes are tracked for the big bets — extend it. Give the outcome owner the mandate to change course, measure value routinely, and when delivery slips, look at the system before the people.

If it's already strong

Keep value measurement feeding prioritisation, keep "done" meaning in-users'-hands, and keep the blameless response to slippage — it's the first thing to erode under pressure.

Go deeper

  • Add “in users’ hands” and “outcome checked” as the last two states on the board, after “dev complete”.
  • For each initiative, name one person accountable for the outcome — not the delivery — and give them room to say “stop”.
  • Run a short, blameless review the next time a date slips: what in the system caused it, one change to make.
🔁

Scrum Toolkit runs every ceremony by the 2020 Scrum Guide in a single page — useful when you're tightening practice and want the format straight. Free public beta.

05Do this in the next two weeks

  • Take (or retake) the maturity check and write down which of practice, flow or ownership scored lowest.
  • For practice: rewrite the definition of done as a team-authored checklist, and give the retro one owned action.
  • For flow: put a WIP limit on the board and start charting cycle time this sprint.
  • For ownership: add "in users’ hands" as a board state, and name an outcome owner for each live initiative.
  • Book a blameless system review for the next slipped date — 30 minutes, one change out.
  • Pick the single weakest area, put a named owner and a date on its first move, and leave the other two as "next".

Still stuck?

If the weak area won't move — flow stays lumpy however hard people push, "done" keeps not meaning shipped, the PO can't hold the line — that's the point to bring Jon in on that one problem. A short, hands-on look at how work actually flows and where it stalls, then the specific move: training, a process redesign, or a fractional delivery lead on it.