Write a concise retrospective report from the information below. Scope and intended outcome: [SCOPE AND INTENDED OUTCOME] Timeline and evidence: [TIMELINE AND EVIDENCE] Results: [RESULTS] What helped and what hindered: [TEAM OBSERVATIONS] Participants and next review: [PARTICIPANTS AND REVIEW] Ask up to 3 clarifying questions only if a required input is missing. Do not invent dates, metrics, decisions, causes, contributions, customer impact, or commitments. Keep the tone factual and blameless: examine process, decisions, information, capacity, and controls rather than assigning personal fault. Produce a report of 600 to 900 words with these sections: 1. Executive summary: scope, intended outcome, actual outcome, and the most important lesson. 2. What happened: a dated timeline of relevant events, decisions, changes, and handoffs. 3. Results versus plan: table with intended measure, actual measure, source or confidence level, and variance. 4. What worked: practices worth repeating, tied to evidence. 5. What did not work: specific failure modes and their impact. Separate confirmed contributing factors from hypotheses needing validation. 6. Lessons and actions: no more than five actions. Each must have an accountable owner, due date, expected effect, and a verification measure. 7. Open questions and next review. Do not use vague action items such as “communicate better.” Before answering, check that the timeline does not contradict the results and that every action addresses a stated lesson. Flag missing evidence or disputed claims clearly.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [SCOPE AND INTENDED OUTCOME] | Describe the project, event, period covered, planned outcome, and success measures. | August onboarding-email redesign; raise trial-to-activation from 31% to 36% without increasing support tickets. |
| [TIMELINE AND EVIDENCE] | Paste key dates, decisions, handoffs, incident notes, meeting notes, and factual sources. | Aug 2 copy approved; Aug 6 engineering found event tracking mismatch; Aug 12 launch; Aug 19 support reported password-reset confusion. |
| [RESULTS] | Provide the actual outcomes, metrics, quality results, customer feedback, and any comparison to plan. | Activation reached 34%; support tickets rose 8% in week one then returned to baseline after copy changed on Aug 21. |
| [TEAM OBSERVATIONS] | List participant observations about helpful practices, blockers, surprises, and possible causes. | Early user interviews improved the first email. Tracking QA began after copy approval. The reset link was visually weak on mobile. |
| [PARTICIPANTS AND REVIEW] | List people or roles who own follow-up and the desired date for reviewing actions. | Growth lead Maya, lifecycle marketer Evan, engineer Priya; review action status on September 15. |
How to use
- Collect the timeline and outcome data before the meeting so discussion does not depend on memory.
- Ask participants to distinguish what they observed from what they think caused it.
- Replace role-only owners with one person who accepts the follow-up action and due date.
- Send this follow-up: “Here is the action-status update and latest measure. Revise only the actions section and flag items that should be closed or escalated.”
Variations
Incident review
Use this after a service, security, or customer-impacting incident.
Write a blameless incident retrospective for [INCIDENT] using [TIMELINE], [IMPACT DATA], [TECHNICAL EVIDENCE], and [FOLLOW-UP OWNERS]. Include impact and duration, detection, response timeline, contributing conditions separated from root causes supported by evidence, what limited impact, and prioritized corrective actions. Each action needs an owner, due date, and verification signal. Avoid naming individuals as causes or asserting root cause before investigation confirms it. Flag security, legal, or customer-notification decisions requiring the responsible professional. Ask up to 3 questions only if essential facts are missing.
Sprint retrospective
Use this at the end of a delivery sprint with a team that needs a short action list.
Create a sprint retrospective from [SPRINT GOAL], [COMPLETED AND CARRIED WORK], [DELIVERY DATA], and [TEAM NOTES]. Produce a 45-minute meeting agenda, a concise report with wins, friction, and experiments, then select no more than three improvement actions for [NEXT SPRINT]. For every action, name one owner, the behavior or process change, and the measure or observation that will show progress. Separate facts from opinions and do not convert criticism of a person into a process conclusion. Ask up to 3 questions only if needed.
Executive recap
Use this when leaders need the decisions and implications rather than full meeting notes.
Turn these retrospective notes into a 350-word executive recap: [RETROSPECTIVE NOTES]. The audience is [AUDIENCE], and the requested decision or support is [REQUEST]. Include outcome versus plan, two evidence-based lessons, the top actions with owners and dates, material risks, and the specific decision needed. Omit debate details and personal attribution unless necessary for accountability. Do not claim a cause, financial impact, or completed action without supplied evidence. Ask up to 3 clarifying questions only if a required input is missing.
Tips
- Use a timeline built from records before the discussion; people often remember sequence differently after a difficult outcome.
- Pair every lesson with an observable change and a check date, otherwise a retrospective becomes a summary rather than operational learning.
- Limit actions to the capacity the team can actually carry alongside current work; deferred actions should have an explicit disposition.
- For sensitive incidents, separate facts established in the review from unresolved hypotheses so the report remains useful as evidence changes.
FAQ
How long should a retrospective report be?
Use enough detail to explain the outcome and actions, usually one to two pages for a normal project phase. Link to raw logs, dashboards, and notes instead of copying them into the report.
Should a retrospective name people?
Name action owners and decision roles when accountability requires it. Do not frame an individual as the cause when the evidence points to a process, control, workload, or information failure.
What if the team disagrees on the cause?
Record the disagreement as an open question and design a way to test it. Do not present a majority opinion as an established fact.