Retrospective action items state machine
Tracking action items from retrospective through closure.
Most teams run retrospectives but never track whether their action items actually stick. This state machine documents the full lifecycle: Proposed (the idea), Committed (the team agrees it's worth doing), In_Progress (someone is actually working on it), Done (they finished), Verified (the team confirmed it worked), and Closed (it's documented so the next retrospective remembers it).
The transitions make clear where action items commonly get stuck: Blocked (waiting on a dependency), Deferred (deprioritized), or lost between Done and Verified (where most process improvements silently fail). Once you can track these states across sprints, you can measure retrospective ROI: how many committed items make it to Verified, and which transitions are bottlenecks.
When to use this template
- Agile coaching — show teams that "done" is not the same as "verified." This diagram is the difference between action items that matter and action items that get forgotten.
- Metrics and tracking — if you're measuring retrospective effectiveness, chart the velocity from Proposed to Verified. Teams that move items quickly to Verified have high-impact retros; teams stuck in Committed or Blocked have process or dependency problems.
- Incident postmortems — use the same state machine for postmortem action items; the structure is identical, and it forces you to check that fixes actually happened, not just got assigned.
How to adapt it
Extend the state machine to match your team's rhythm:
- Add sprint-boundary transitions — items can stay In_Progress for one sprint; if they spill into a second, escalate them or move them to Blocked.
- Insert a stakeholder sign-off state between Verified and Closed if another team needs to approve the change before it counts as done.
- Add rejection paths — Done can transition back to Proposed if verification finds the fix didn't work; that keeps your team honest about what "done" means.
The visual editor makes it easy to sketch your exact cycle — your changes regenerate clean Mermaid state-diagram syntax, so the result fits straight into your team's agile documentation or Miro board.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
stateDiagram-v2
[*] --> Proposed
Proposed --> Committed: Team agrees
Committed --> In_Progress: Owner assigned
In_Progress --> Blocked: Dependency found
Blocked --> In_Progress: Unblocked
In_Progress --> Done: Complete
Done --> Verified: Reviewed & confirmed
Verified --> Closed: Documented
Proposed --> Deferred: Priority downgraded
Deferred --> [*]
Closed --> [*]
Frequently asked questions
- What is a retrospective action items state machine?
- It's a diagram of the lifecycle for an improvement idea that emerges from a retrospective: from the moment someone proposes it, through the team's commitment to work on it, the actual execution, verification that it worked, and documentation. The states make clear what 'done' really means — not just coded, but reviewed, confirmed to work, and recorded for the next retrospective.
- Why separate Blocked from In_Progress?
- Because action items get stuck on dependencies all the time: waiting for another team, waiting for a tool purchase, waiting for data. If you lump Blocked into In_Progress, you can't tell how much team time is actually stuck versus actively working. Separating them makes it visible when to escalate or unblock.
- Why is Verified different from Done?
- Done means the person assigned finished the work. Verified means the team checked it worked and brought the value the retrospective intended. This split catches the common case where an action item gets done but nobody checks whether it actually solved the problem.
- How do I adapt this for our sprint cycle?
- Add a sprint-number node at the top or add a timestamp guard on transitions: In_Progress can only stay there for one sprint before escalating to Blocked or Done. Or add Deferred transitions from any state if priorities shift mid-sprint. The visual editor lets you add states and transitions without YAML syntax, so you can model your exact process.