Complete firstClosed eventnot in catalog
The event, sprint, incident, or project phase has ended and the actual outcome can be observed.
Without: Without a closed event, the review becomes speculative and the team cannot compare intent with reality.
RunsheetOperations
After-Action Review
ComplexityLow
Time20-45 min
Participants3-12
FormatWorkshop + async
MaturityEstablished
01
Prerequisite
What needs to be finished first
02
Preparation
What needs to be ready before start
Materials
Timeline, metrics or logs, notes from the event, a shared document or board, and a timer.
People / roles
One facilitator, the people involved in the event, and optionally a scribe when the group is larger.
Pre-read
The intended outcome, the observed result, relevant evidence, owners, and the review timebox.
Time needed
20-45 min
Setup
Create a simple page with the five review prompts and space for actions. Keep the evidence visible so the conversation stays anchored.
03
Core question
The one question this method answers
What was intended, what actually happened, why were there gaps, and what should the team do next time?
04
Flow
Marker: Minute
| Step | Duration | Action | Hint |
|---|---|---|---|
10-5 min | 5 min | State the intended outcome and the scope of the event or phase. Agree on what is in and out of the review. | If the goal is still fuzzy, the review will drift. Start with the concrete result that should have happened. |
25-12 min | 7 min | Describe the actual sequence of events in order. Use evidence, not memory alone. | If people start explaining early, bring them back to the timeline first. Sequence comes before judgment. |
312-20 min | 8 min | Compare intent and reality and explain the largest deviations or surprises. | Do not jump from deviation to blame. Name the gap clearly and keep the explanation mechanism-focused. |
420-30 min | 10 min | Collect lessons and patterns that are reusable beyond this one event. | If the lessons stay too general, ask what the team would repeat, avoid, or measure differently next time. |
530-45 min | 15 min | Turn the lessons into concrete actions with owner and follow-up date, then close the review. | If no action is owned, the learning will vanish. Keep the number of actions small and specific. |
05
Artifact
What comes out at the end
Form
A short review note with intent, actual result, deviations, lessons learned, and action items.
Versioning / ownership
Add date, event ID, and owner in the header. Keep the action items linked to the tracking system and leave the evidence trail readable.
Tool alternatives
- Markdown in the project repository
- Confluence page in the team space
- Notion page with a review template
- Linear or Jira issue with a linked summary
after-action-review-working-template.md
Compact working template for After-Action Review with context, input, output artifacts, and next step.
After-Action Review Working Template
Goal
A short review of what was intended, what happened, and why.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Lessons Learned:
- Action Items:
- Event Summary:
Assumptions and open questions
- ...
Decision / Next step
Owner, date, and success signal.
06
Example output
Concrete filled scenario, fictional example
after-action-review-beispiel.md
Concrete filled scenario, fictional example
After-Action Review - Release 2.4 incident, 2026-07-01
Intended result: Deploy the patch without user-facing downtime.
Actual result: The deploy finished 18 minutes late and two rollbacks were triggered.
Main deviation: The database migration took longer than expected because the staging test did not include production data volume.
Lessons learned
- Production-sized data needs to be part of pre-release checks.
- Rollback decisions should be pre-agreed before the deploy starts.
Actions
- Add production-sized migration checks to the release checklist.
- Define rollback thresholds for future releases.
07
Pitfalls
Recognize symptoms and steer against them
Trap
The baseline is missing
Symptom
No one states what success looked like, so the review cannot compare intent and reality.
What to do
Start by writing the intended result in one sentence before discussing anything else.
Trap
The review turns into blame
Symptom
People explain failures by naming people instead of describing conditions and mechanisms.
What to do
Redirect every explanation toward the sequence, the system, and the evidence.
Trap
Lessons stay abstract
Symptom
The group leaves with broad statements like "communicate better" and nothing reusable.
What to do
Ask what exactly will be repeated, avoided, or measured next time.
Trap
Too many actions are created
Symptom
The team writes a long list and no action gets finished.
What to do
Keep only the few actions that are truly owned and followable.
Trap
Evidence is ignored
Symptom
The timeline or logs exist but the discussion stays purely anecdotal.
What to do
Bring the strongest evidence into the room and anchor the review around it.
08
Stop criteria
Done signals checkable in under a minute
The event is not closed yet.
There is no shared evidence base for the discussion.
The group wants a performance review instead of a learning review.
The people who can explain the outcome are absent and cannot join asynchronously.
No one is willing to own follow-up actions.
The outcome is still changing, so the review would be too early.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.