# Scrum Health Check

> Not a compliance audit. Running every event correctly while getting none of the benefit is the
> normal failure, so this checks behaviour rather than attendance.
>
> Run it with the team, not about the team.

**Team:** _______________  **Date:** _______  **Sprint length:** ____

## 1. Definition of done — the highest-value question

- [ ] Written down, and the team can state it without looking
- [ ] Includes **tested**
- [ ] Includes **deployable**
- [ ] Includes documentation where relevant
- [ ] Nothing is "done except…"

🔴 If testing, review or deployment sit outside "done", the sprint produces a claim rather than an
increment, and the untested remainder accumulates into a hardening phase — the exact thing sprints
were meant to eliminate.

**Is the increment genuinely releasable at the end of each sprint?** yes / no

## 2. The commitment

- [ ] The **team** decides how much it takes on
- [ ] Nobody outside the team sets the sprint contents
- [ ] The sprint has a **goal**, expressed as an outcome, not a list of tickets
- [ ] Work is not routinely added mid-sprint
- [ ] Capacity is reserved for support and interruptions, and the reservation is realistic

**Unplanned work as a share of the last three sprints:** ____%

If that number is consistently high, the work is flow-shaped and a sprint commitment is the wrong
instrument. Consider [Kanban](/pmo/kanban/) — that is a sensible decision, not a failure.

## 3. Velocity

- [ ] Used only for the team's own planning
- [ ] **Not reported outside the team**
- [ ] Not compared against another team
- [ ] Not a target, and not in anyone's objectives

🔴 Velocity leaving the team is where the numbers start becoming fiction. It inflates reliably,
without anyone deciding to cheat.

## 4. The events

| Event | Happening? | Actually working? |
|---|---|---|
| Sprint planning | | produces a goal, not just a filled sprint |
| Daily scrum | | **team coordinating**, not reporting to a manager |
| Sprint review | | stakeholders see working software and **change the backlog** |
| Retrospective | | produces owned actions |

- [ ] The daily is 15 minutes and run by the developers
- [ ] No manager receives status in the daily
- [ ] The sprint review changes what gets built next — if stakeholders never redirect anything,
      they are being informed rather than consulted

## 5. Retrospectives

- [ ] Produce at least one **owned, dated action** per sprint
- [ ] Last sprint's actions were reviewed at this one
- [ ] The same issue is not raised repeatedly with nothing changing
- [ ] People say uncomfortable things

**Actions from the last three retrospectives: ____ raised, ____ completed.**

If the second number is much smaller, the retrospective is theatre and attendance will decline.

## 6. Roles

- [ ] A product owner exists, is available, and **can decide without escalating**
- [ ] The scrum master spends most of their time removing impediments **outside** the team
- [ ] One person is not both product owner and scrum master
- [ ] The team decides how the work is done

**Average time to get a decision from the product owner:** ____

That number is a cap on the team's cycle time, whatever the process says.

## 7. Sprint outcomes

| Sprint | Committed | Completed | Carried over | Goal met? |
|---|---|---|---|---|
| | | | | |
| | | | | |
| | | | | |

Consistently finishing far less than planned is data about planning or interruptions. It is worth
a retrospective, not guilt.

## Verdict

| | |
|---|---|
| Definition of done includes tested + deployable | yes / no |
| Team sets its own commitment | yes / no |
| Velocity stays inside the team | yes / no |
| Retrospective actions get done | yes / no |
| Increment genuinely releasable | yes / no |

**Four or five "no" answers means the ceremonies are running without the operating model.** Fix the
definition of done first — it is upstream of most of the others.