After action review and retrospective

Origin

US Army (AAR format, TC 25-20); Norman Kerth (project retrospectives), 1970s trials; TC 25-20 (1993); Kerth (2001)

Level

301 · Advanced

Fits

Startup, Small and mid-size, Scale-up, Enterprise

Time to apply

45 to 60 minutes for a first review, held within days of the event

What you need

a recent event with a clear intent, such as a launch, an incident or a sprint · the people who did the work, in the room together · the numbers or logs that show what actually happened · a facilitator who did not run the event, or a leader who will not dominate

An after action review is a short, structured conversation in which the people who did a piece of work compare what they meant to do with what happened, work out why the two differ, and decide what to keep and what to change. The US Army’s 1993 guide, TC 25-20, defines it as a professional discussion focused on performance standards, in which soldiers discover for themselves what happened, why, and how to sustain strengths and improve on weaknesses. Business teams use the same shape under other names: debrief, retrospective, postmortem.

Where does the after action review come from?

It comes from US Army training research in the 1970s. The Army Research Institute’s history of the method says its first reported uses came with two training systems that gave trainers an objective record of who hit whom: SCOPES for infantry, and REALTRAIN for armor. Training circulars for them were published in 1973 and 1975 (Morrison and Meliza, 1999). When the National Training Center began force-on-force exercises in 1982, it relied on the AAR as its main feedback method, which raised the method’s profile.

The practice reached business readers through Marilyn Darling, Charles Parry and Joseph Moore, whose 2005 Harvard Business Review article was written with a former commander of the Army’s opposing force at the NTC. The Army’s current guidance is TC 7-0.1, published in 2025 (US Army).

Software teams reached the same idea from another side. Norman Kerth’s 2001 book Project Retrospectives set out how to review a whole project. Esther Derby and Diana Larsen’s Agile Retrospectives, published in 2006 with a foreword by Ken Schwaber, brought the practice to agile teams, and the twelfth principle of the Agile Manifesto asks teams to reflect at regular intervals on how to become more effective. We found no source that traces a direct line from the Army format to Kerth’s method, so we treat them as parallel developments with a shared logic.

How does an after action review work?

It follows a fixed order: intent, outcome, cause, action. TC 25-20 lists the format as an introduction and rules, a review of objectives, the commander’s intent (“what was supposed to happen”), a summary of events (“what happened”), a discussion of why it happened and how to improve, and closing comments.

Starting from intent matters. Feedback, in TC 25-20’s words, compares the actual output of a process with the intended outcome. Without a written intent, a review turns into a swap of opinions.

The guide also separates a review from a critique. A critique gives one viewpoint, while an AAR invites everyone in, whatever their rank, and says there are always strengths to sustain and weaknesses to improve. It describes a quick informal version too: a squad leader using pinecones to stand in for squad members to walk through a contact on the spot.

What does the research say about debriefs?

Debriefs improve performance, though the evidence comes mostly from training and simulation. Tannenbaum and Cerasoli pooled 46 samples with 2,136 participants and found that debriefs raised effectiveness over a control group by about 25% (d = .67). Effects were similar for teams and individuals. Their four defining elements are active self-learning, developmental rather than evaluative intent, a focus on specific events, and input from more than one source. They also found a pattern for structure: effectiveness fell from d = .69 for highly structured debriefs to .54 for moderate and .32 for none, though almost all studies were at least moderately structured.

A later meta-analysis by Keiser and Arthur covered 61 studies and reported a larger overall effect, d = 0.79. It found that two things consistently mattered: matching the review to the individual or the team that did the work, and using objective performance records. Structure helped in military settings and made little difference in health care. A single experiment with 47 four-person teams by Villado and Arthur found that teams with a review beat teams without one on team performance, efficacy, openness of communication and cohesion, and found no difference between memory-based and recorded reviews.

Health care has adopted the method too. AHRQ’s TeamSTEPPS programme describes team debriefs of about three minutes or less, led by the team leader, and a 2008 paper by Salas and colleagues sets out 12 practices, some for hospital leaders and some for facilitators.

One caution: Allen and colleagues repeat the 25% figure for well-conducted debriefs, which means the number depends on the debrief being done well. A review that is rushed, dominated or never acted on is not the thing these studies measured.

How is it different from a sprint retrospective?

A sprint retrospective is the same logic on a schedule. The Scrum Guide says its purpose is to plan ways to increase quality and effectiveness, caps it at three hours for a one-month Sprint, and says the most helpful changes may be added to the next Sprint Backlog. See Scrum for the full set of events.

Google’s SRE book describes the postmortem version: a written record that focuses on contributing causes without indicting any individual or team, written when defined triggers such as user-visible downtime or data loss are met.

Why do reviews fail, and what fixes them?

Most failures come from fear and from no follow-up. Amy Edmondson’s study of 51 work teams found that psychological safety, the shared belief that the team is safe for interpersonal risk, was linked to learning behavior. Kerth’s answer is a statement he calls the Prime Directive, which asks participants to believe that everyone did the best job he or she could with what they knew. Martin Fowler notes that advice to read it aloud may work through priming, and warns that priming studies have replicated poorly. The statement does not claim nobody errs. It points the group at the system that allowed the error, which is also the stance of 5 whys.

The second failure is a review that ends on a list. TC 25-20 puts a follow-up step after the discussion: retrain or revise procedures immediately and feed the findings into the next plan. PDCA calls this step Act, and kaizen turns it into a habit. David Garvin’s 1993 HBR article opens from the same gap: failed improvement programs outnumber successful ones, and he puts the missing piece down to a commitment to learning. A fixed operating rhythm gives reviews a place to live, so they are not scheduled only after something breaks.

Ellis and Davidi add a third point from a field experiment with soldiers: navigation performance improved more when soldiers reviewed successes and failures, compared with failures only. Review what worked as seriously as what did not. A Growth Lab plan builds reviews into the monthly cycle: see Growth Lab.

How to apply After action review and retrospective, step by step

1. Put the review in the calendar before the work starts. TC 25-20 asks leaders to plan reviews six to eight weeks out, at the same time as the training plan. Book the slot and the room now. Result: a dated review that cannot be dropped when the week gets busy.
2. State the intent in one paragraph. Write what was supposed to happen, with the target and the date, before the event. Result: a plan that the outcome can be compared with, so nobody argues about what 'success' meant.
3. Reconstruct what happened from facts. Walk through the event in order with the data and the people who were there. Ask for input from several people, not one. Result: a shared timeline that everyone accepts.
4. Ask why for the biggest gaps, and for the best results. Take the two or three largest gaps between intent and outcome and ask why. Do the same for something that went better than planned. Result: causes for both, not only for failures.
5. Choose a few changes, each with an owner and a date. Pick the changes that matter most. Write who does what by when, and put it in the same tool as your other work. Result: a short action list that goes into the next plan.
6. Check the changes at the next run. Open the last review's action list at the start of the next one. Ask which changes happened and whether they helped. Result: a loop that closes, not a pile of notes.

Examples

A payments team after a late payout run

Illustrative. Intent: every payout in the batch leaves by 14:00. Outcome: 95% left on time and the last 5% left at 16:30. The gap traces to a manual review queue that filled after a rule change. The team keeps the early file check, sets a review-queue alert at 40 items with a named owner, and checks it at the next payout cycle.

A clinic after a flu-season rush

Illustrative. Intent: phone calls answered within a minute, appointments confirmed the same day. Outcome: the front desk missed a third of calls from 9:00 to 10:00. The review finds the booking system and the phone queue were handled by the same two people. The clinic moves confirmation texts to an automated message and keeps the best-performing greeting script.

A marketing team after a campaign launch

Illustrative. Intent: 300 qualified leads in two weeks. Outcome: 180, with one channel producing most of them. The team asks why that channel worked as well as why the others did not, and writes both answers down. The next brief copies what worked and sets a mid-campaign check on day five.

When to use it

Use it after any event with a clear intent and a team that can change what it does next: a launch, a campaign, an incident, a sprint, a client project. It works best when held within days, while memory is fresh, and when the same group will run something similar again.

When not to use it

Do not use it to rate individuals or to settle blame. Research on debriefs treats developmental, non-punitive intent as a defining feature, and a review that becomes an appraisal stops producing honest answers. Skip it too when nobody has the authority to act on the findings.

Common mistakes

• Turning it into a critique. TC 25-20 says an AAR is not a critique and does not grade success or failure. The moment one person lectures, the rest stop talking.
• Reviewing only failures. Ellis and Davidi found soldiers improved more when they reviewed successes and failures than failures alone.
• Skipping the intent. Without a written plan there is nothing to compare the outcome with, and the discussion becomes opinion.
• Ending with a list of lessons and no owners. The Scrum Guide says the most impactful improvements should be addressed as soon as possible, and they may be added to the next Sprint Backlog.
• Holding the same meeting every time. Atlassian's team playbook suggests varying the format so the retrospective does not become a box to tick.

FAQ

What is an after action review?

An after action review is a structured discussion held soon after an event. The people involved compare what was meant to happen with what happened, find out why, and decide what to sustain and what to improve. TC 25-20, the US Army guide of 1993, describes it as a professional discussion focused on performance standards.

What is the difference between an after action review and a retrospective?

They share the same logic. An AAR is tied to a single event and compares outcome with a stated intent, often within hours. A sprint retrospective is a recurring team event at the end of each Sprint that looks at people, process and tools. Kerth's project retrospective looks back at a whole project.

How long should an after action review take?

TC 25-20 suggests about 30 to 45 minutes for a platoon, an hour for a company and about two hours for a battalion. The Scrum Guide caps a Sprint Retrospective at three hours for a one-month Sprint. TeamSTEPPS describes a quick team debrief of about three minutes or less.

Do after action reviews actually improve performance?

Evidence says yes. A 2013 meta-analysis of 46 samples (Tannenbaum and Cerasoli) found debriefs improved effectiveness by about 25% over control groups (d = .67). A 2021 meta-analysis of 61 studies (Keiser and Arthur) reported a larger overall effect of d = 0.79. Both are mostly training and simulation studies.

What is the Prime Directive in a retrospective?

It is a statement Norman Kerth put in his 2001 book Project Retrospectives. It asks participants to believe that everyone did the best job he or she could, given what they knew, their skills, the resources and the situation. Facilitators often read it aloud at the start to make the session safe.

Sources

1. US Department of the Army, TC 25-20: A Leader's Guide to After-Action Reviews, 1993
2. US Army, TMD publishes training circular to augment FM and ADP 7-0 (TC 7-0.1, After Action Reviews), 2025
3. John E. Morrison and Larry L. Meliza, Foundations of the After Action Review Process, US Army Research Institute Special Report 42, 1999
4. Scott I. Tannenbaum and Christopher P. Cerasoli, Do team and individual debriefs enhance performance? A meta-analysis, Human Factors 55(1), 2013
5. Nathanael L. Keiser and Winfred Arthur Jr., A meta-analysis of the effectiveness of the after-action review (or debrief) and factors that influence its effectiveness, Journal of Applied Psychology, 2021
6. Anthony J. Villado and Winfred Arthur Jr., The comparative effect of subjective and objective after-action reviews on team performance on a complex task, Journal of Applied Psychology, 2013
7. Joseph A. Allen, Roni Reiter-Palmon, John Crowe and Cliff Scott, Debriefs: Teams learning from doing in context, American Psychologist 73(4), 2018
8. Shmuel Ellis and Inbar Davidi, After-event reviews: Drawing lessons from successful and failed experience, Journal of Applied Psychology 90(5), 2005
9. Amy C. Edmondson, Psychological safety and learning behavior in work teams, Administrative Science Quarterly 44(2), 1999
10. Marilyn Darling, Charles Parry and Joseph Moore, Learning in the thick of it, Harvard Business Review, July-August 2005
11. David A. Garvin, Building a learning organization, Harvard Business Review, July-August 1993
12. Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020
13. Agile Manifesto authors, Principles behind the Agile Manifesto
14. Norman L. Kerth, Project Retrospectives: A Handbook for Team Reviews, Dorset House, 2001 (eBook edition, InformIT)
15. Martin Fowler, Priming Prime Directive, martinfowler.com
16. Esther Derby and Diana Larsen, Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, 2006
17. Atlassian, Team Playbook: Sprint retrospective
18. Google, Site Reliability Engineering, chapter 15: Postmortem culture
19. AHRQ, TeamSTEPPS: Reviewing the team's performance, debrief
20. Eduardo Salas, Cameron Klein, Heidi B. King and others, Debriefing medical teams: 12 evidence-based best practices and tips, Joint Commission Journal on Quality and Patient Safety 34(9), 2008 (AHRQ PSNet record)

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn