Scrum Health Check
An honest check on whether scrum is working — definition of done, who sets the commitment, whether velocity has left the team, and whether retrospectives change anything.
Markdown. No sign-up, no email.
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 — 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.