Sprint Retrospective Templates | Actionable Formats
Use structured retrospective templates like Start/Stop/Continue, 4Ls, and Sailboat. GitScrum tracks action items and measures improvement over time.
8 min read
Effective retrospectives require structure. Without templates, discussions meander, action items get lost, and teams repeat the same problems. A good retrospective template guides conversation, captures insights, and tracks follow-through on improvement actions.
Retrospective Template Formats
| Format | Best For | Structure |
|---|---|---|
| Start/Stop/Continue | Quick retros | 3 columns, simple |
| 4Ls | Deeper reflection | 4 categories, balanced |
| Mad/Sad/Glad | Emotional check-in | Feelings-based |
| Sailboat | Visual teams | Metaphor-driven |
| 5 Whys | Root cause | Problem-focused |
Classic Templates
START / STOP / CONTINUE
═══════════════════════
TEMPLATE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ │
│ START STOP CONTINUE │
│ (Begin doing) (Stop doing) (Keep doing) │
│ ───────────── ──────────── ─────────── │
│ │
│ □ Pair programming □ Skipping code □ Daily async │
│ on complex tasks reviews standups │
│ │
│ □ Document □ Late scope □ Sprint │
│ architecture changes planning │
│ decisions session │
│ │
│ □ Dedicated □ Meetings during □ Blockers │
│ tech debt time focus hours in Slack │
│ │
└─────────────────────────────────────────────────────────────┘
4Ls RETROSPECTIVE
═════════════════
TEMPLATE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ │
│ LIKED LEARNED │
│ (What went well) (New insights) │
│ ───────────────────── ────────────────── │
│ □ Team collaboration □ GraphQL is faster │
│ on Feature X than REST for this │
│ □ Fast PR reviews □ Need buffer for │
│ □ Clear requirements integration testing │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ LACKED LONGED FOR │
│ (What was missing) (Wish we had) │
│ ───────────────────── ────────────────── │
│ □ Test coverage on □ Better monitoring │
│ payment module dashboards │
│ □ Clear ownership □ More time for │
│ on shared code refactoring │
│ □ Design specs early □ Staging environment │
│ │
└─────────────────────────────────────────────────────────────┘
MAD / SAD / GLAD
════════════════
TEMPLATE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ │
│ 😠 MAD │
│ (Frustrating things) │
│ ───────────────────── │
│ □ Production incident during demo │
│ □ Unclear priorities mid-sprint │
│ □ Flaky tests blocking CI │
│ │
│ 😢 SAD │
│ (Disappointing things) │
│ ───────────────────── │
│ □ Didn't finish the payment feature │
│ □ Lost momentum on tech debt │
│ □ Bob leaving the team │
│ │
│ 😊 GLAD │
│ (Positive things) │
│ ───────────────────── │
│ □ Shipped mobile app v2.0 │
│ □ New team member onboarded well │
│ □ Zero production incidents this sprint │
│ │
└─────────────────────────────────────────────────────────────┘
Visual Templates
SAILBOAT RETROSPECTIVE
══════════════════════
🏝️ ISLAND (Goal)
"Ship v3.0"
│
│
☀️ Wind │ ⚓ Anchor
(Helping) │ (Holding back)
───────── │ ─────────────
• Clear specs │ • Legacy code
• Team skill │ • Slow CI
• Good tools ⛵ • Unclear reqs
/│\
/ │ \
/ │ \
/ │ \
/ │ \
/ │ \
/ │ \
~~~~~~~~│~~~~~~~~~
│
🪨 Rocks
(Risks)
────────
• Team burnout
• Dependency delays
• Scope creep
HOT AIR BALLOON
═══════════════
🎈 SANDBAGS (Drop)
What to stop
• Unnecessary meetings
• Scope changes mid-sprint
│
│
┌───┴───┐
│ │
│ 🧺 │ 🔥 FIRE (Keep burning)
│ │ What helps us rise
└───────┘ • Daily async updates
│ • Pair programming
│ • Fast deployments
│
☁️ CLOUDS (Obstacles)
Slow code reviews
Unclear ownership
Flaky tests
Data-Driven Template
METRICS-BASED RETROSPECTIVE
═══════════════════════════
SPRINT 14 DATA SUMMARY:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ │
│ VELOCITY │
│ ───────── │
│ Committed: 42 pts Completed: 38 pts Ratio: 90% │
│ Trend: ↗ +5% vs 4-sprint avg │
│ │
│ CYCLE TIME │
│ ────────── │
│ Average: 3.2 days Best: 0.5 days Worst: 8 days │
│ Trend: ↘ -12% improvement │
│ │
│ BLOCKERS │
│ ──────── │
│ Total: 5 blockers Avg resolution: 1.2 days │
│ Types: 3 dependencies, 1 unclear req, 1 environment │
│ │
│ BUGS │
│ ──── │
│ Found in sprint: 8 Fixed: 6 Escaped to prod: 1 │
│ Trend: ↘ -25% fewer bugs │
│ │
└─────────────────────────────────────────────────────────────┘
ANALYSIS QUESTIONS:
─────────────────────────────────────
1. Why did we miss 4 points? (38 vs 42)
└── 1 task blocked for 3 days by API dependency
2. What caused the 8-day cycle time outlier?
└── Unclear requirements, 3 rounds of revision
3. How can we reduce blockers further?
└── Earlier dependency identification in planning
4. What contributed to fewer bugs?
└── Pair programming on complex features
Action Item Tracking
ACTION ITEMS IN GITSCRUM
════════════════════════
CREATING IMPROVEMENT TASKS:
─────────────────────────────────────
From retrospective, create GitScrum tasks:
┌─────────────────────────────────────────────────────────────┐
│ Task: [RETRO] Implement pair programming for complex tasks │
├─────────────────────────────────────────────────────────────┤
│ │
│ Type: Improvement │
│ Sprint: 15 │
│ Assignee: Tech Lead │
│ Labels: retrospective, process │
│ │
│ Description: │
│ From Sprint 14 retro: Start pair programming on tasks │
│ estimated at 5+ points to reduce bugs and knowledge silos. │
│ │
│ Acceptance Criteria: │
│ □ Define pairing schedule for Sprint 15 │
│ □ Track which tasks used pairing │
│ □ Review results in Sprint 15 retro │
│ │
└─────────────────────────────────────────────────────────────┘
ACTION TRACKING BOARD:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ Retrospective Actions - Q1 2026 │
├─────────────────────────────────────────────────────────────┤
│ │
│ TO DO IN PROGRESS DONE │
│ ────── ─────────── ──── │
│ │
│ □ Fix flaky □ Implement ✓ Daily async │
│ tests pairing standups │
│ ✓ Sprint │
│ □ Staging □ Document planning doc │
│ environment decisions │
│ ✓ PR review │
│ □ Monitoring automation │
│ dashboards │
│ │
└─────────────────────────────────────────────────────────────┘
COMPLETION METRICS:
─────────────────────────────────────
Q1 Action Items:
├── Created: 12
├── Completed: 8 (67%)
├── In Progress: 2
├── Dropped: 2 (no longer relevant)
└── Avg completion time: 2.3 sprints
Retrospective Meeting Flow
45-MINUTE RETROSPECTIVE AGENDA
══════════════════════════════
PHASE 1: SET THE STAGE (5 min)
─────────────────────────────────────
□ Check-in question
□ Review previous action items
□ Set focus for this retro
PHASE 2: GATHER DATA (15 min)
─────────────────────────────────────
□ Review sprint metrics (velocity, cycle time)
□ Silent brainstorming on template
□ Each person writes 3+ items
□ Add to shared board
PHASE 3: GENERATE INSIGHTS (15 min)
─────────────────────────────────────
□ Group similar items
□ Vote on most important (3 votes each)
□ Discuss top 3 items
□ Identify root causes
PHASE 4: DECIDE ACTIONS (8 min)
─────────────────────────────────────
□ Define 2-3 action items
□ Assign owners
□ Set due dates
□ Add to sprint backlog
PHASE 5: CLOSE (2 min)
─────────────────────────────────────
□ Summarize decisions
□ Thank participants
□ Schedule next retro
Measuring Improvement
RETROSPECTIVE EFFECTIVENESS TRACKING
════════════════════════════════════
SPRINT-OVER-SPRINT COMPARISON:
─────────────────────────────────────
S12 S13 S14 Trend
────────────────────────────────────────────
Velocity 38 40 42 ↗
Cycle Time (days) 4.1 3.6 3.2 ↘
Bugs Escaped 3 2 1 ↘
Action Completion 60% 70% 80% ↗
Team Happiness 7.2 7.5 7.8 ↗
RECURRING ISSUE TRACKER:
─────────────────────────────────────
Issue: "Unclear requirements"
├── Sprint 10: Raised
├── Sprint 11: Action created
├── Sprint 12: In progress
├── Sprint 13: Still occurring (reduced)
├── Sprint 14: Resolved ✓
└── Root cause: Added requirement template
Issue: "Slow code reviews"
├── Sprint 11: Raised
├── Sprint 12: Action created (PR automation)
├── Sprint 13: Implemented
├── Sprint 14: Monitoring
└── Status: 50% faster, continue monitoring