Sprint Retrospective

Purpose: Reflect on the sprint to reinforce what's working and commit to specific improvements

How to run this meeting

Rotate the facilitator role every sprint — this distributes ownership and prevents the retro from feeling like a manager-led performance review. Whoever facilitates should not be the person doing most of the talking. Choose a structured format and stick with it for 2–3 sprints before switching, so the team can compare results over time. Popular formats include 4Ls (Liked, Learned, Lacked, Longed for), Start/Stop/Continue, and Sailboat (wind = momentum, anchors = blockers, rocks = risks). The format matters less than the consistency.

Start every retro by reviewing the action items from the previous sprint's retro. If you skip this step, action items become meaningless theater. If items weren't completed, discuss why before adding new ones. The most common retro anti-pattern is generating a long list of improvements that nobody owns or follows up on — guard against this by capping new action items at three per sprint.

Time-box each section ruthlessly. With a 60-minute retro, spend roughly 5 minutes on last sprint's actions, 10 minutes on data/context, 15 minutes on individual reflection, 20 minutes on discussion, and 10 minutes on action items. Psychological safety is the prerequisite for a useful retro — if your team won't say what's actually wrong, that's the problem to solve first.

Before the meeting

• Review last sprint's action items and note their status
• Pull sprint metrics: velocity, bug count, deployment frequency, incidents
• Send the meeting format to attendees 24 hours in advance so they can reflect
• Prepare a shared board (physical sticky notes or a digital equivalent like FigJam or Miro)
• Ensure the whole team is present — retros without key members miss critical perspectives

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–75 minutes
• Sprint:

---

Previous Action Items Review

Check in on commitments from last retro. Mark each as Done, In Progress, or Dropped (with reason).

---

What Went Well

Things to reinforce and protect. Be specific — "good communication" is not useful, "we caught the auth bug before it hit production because of our new PR checklist" is.

• Pair programming on the billing module caught 3 bugs before review — keep doing this for high-risk features
• Daily standups stayed under 15 minutes for the first time in months
• @mia's runbook for the payments service made the Friday incident recovery much faster

---

What Didn't Go Well

Friction, failures, and frustration. Focus on systems and processes, not individuals.

• Sprint scope crept 40% — two unplanned tickets got added mid-sprint without discussion
• CI pipeline broke twice and no one owned the fix for 6+ hours
• Three tickets were marked "done" but still needed design review — our definition of done needs updating

---

What We Learned

New knowledge, surprises, and things that changed your assumptions.

• The new caching layer reduced API latency by 60% in staging — more than we expected
• Customers are using the bulk export feature daily; we thought it was a power-user edge case
• Our test suite takes 22 minutes to run; this is now blocking fast iteration

---

Experiments for Next Sprint

Specific, time-boxed changes to try. Frame as hypotheses: "If we do X, we expect Y."

• Experiment: Add a 15-minute "scope lock" check on day 3 of the sprint to catch creep early
  • Hypothesis: We'll complete 90%+ of committed tickets without adding unplanned work
• Experiment: Assign a rotating CI owner for the week
  • Hypothesis: Pipeline issues will be resolved in under 2 hours on average

---

Action Items

Follow-up

The facilitator publishes the retro notes to the team channel within 24 hours. Action items are added to the next sprint's backlog so they're visible. The next sprint's facilitator is announced at the end of the meeting. Notes are archived so the team can spot trends across retros over time.