Retrospective Frameworks
Structured formats for running post-analysis retrospectives. Pick the one that matches the tone, team size, and depth needed.
Framework 1: Start / Stop / Continue
Best for: quick solo or small-team retros (30 minutes)
Three columns:
| Start | Stop | Continue |
|---|---|---|
| What should we begin doing that we aren't doing yet? | What are we doing that's wasting time or causing harm? | What's working and should be preserved? |
How to run it:
- Each person writes 2–3 items per column (silent, 5 min)
- Read out and group similar items (10 min)
- Vote on top 2 items from "Start" and top 1 from "Stop" to action (5 min)
- Assign owners and due dates (5 min)
Best for: Teams that know each other; quick process check-in; when time is limited.
Framework 2: The 4Ls
Best for: deeper reflection on a completed project
Four sections:
| Liked | Lacked | Learned | Longed for |
|---|---|---|---|
| What did you enjoy or found effective? | What was missing or felt insufficient? | What do you know now that you didn't before? | What do you wish had been different? |
How to run it:
- Write independently for 10 minutes (all four sections)
- Share in round-robin (20 min)
- Identify patterns across people's responses (10 min)
- Prioritise 2–3 learnings to capture permanently (5 min)
- Assign action items (5 min)
Best for: Post-project deep-dives; projects with multiple people; when the team has strong opinions.
Framework 3: The Timeline Retro
Best for: projects where sequencing and timing were the main issues
How to run it:
- Draw a timeline of the project from start to delivery
- Mark key events: decisions made, surprises encountered, delays hit, wins
- For each: "what do we know now that we didn't then?"
- Identify the 2–3 earliest points where a different decision would have helped most
Best for: Post-mortems on late or troubled projects; identifying where things went wrong earliest.
Framework 4: Solo Retrospective (10-minute version)
For individuals completing a project without a team retro.
Answer these 5 questions in writing:
- What was the single biggest time sink? Would I handle it differently?
- What did I underestimate in the planning? How do I adjust estimates next time?
- What do I now know about the data / tools / domain that I should document?
- Did the output land well with the stakeholder? What worked, what didn't?
- What's the one thing I'd change if I were starting this project today?
What Makes a Good Retro Action Item
| Poor action item | Better action item |
|---|---|
| "Improve communication" | "Send a requirements doc to stakeholders before every project over 2 hours" |
| "Better data quality checks" | "Add qa_runner.py to the delivery checklist by [date]" |
| "Get better at estimating" | "Log actuals vs. estimates for the next 5 projects and review at the next retro" |
| "Document findings" | "Add a 30-min 'write findings summary' task to every analysis plan template" |
Good action items are:
- Specific (what exactly)
- Owned (by whom)
- Time-bound (by when)
- Measurable (how you'll know it's done)