Sprint Retrospective Template: Guide, Formats, and Best Practices

The most skipped ceremony in Scrum is the retrospective. Teams claim they lack time, but the real reason is that retrospectives feel performative—everyone says the sprint went fine, the Scrum Master captures vague action items that no one remembers next sprint, and the same problems repeat indefinitely.

Effective sprint retrospectives require structure. After facilitating 45+ retrospectives across agile transformations, software development sprints, and consulting engagements, we have tracked which formats generate actionable insights (Start Stop Continue, 4Ls, Sailboat) and which turn into complaint sessions with no behavioral change. The difference comes down to the template: teams that rotate formats, timebox discussions, and assign owners to action items improve their velocity and team satisfaction scores by measurable margins. Teams that run the same generic retro every sprint see no improvement.

This guide covers seven proven retrospective formats, facilitation scripts, and best practices for turning reflections into action.

What Is a Sprint Retrospective?#

A sprint retrospective is a Scrum ceremony where the team reflects on their process and identifies improvements for the next sprint. The Scrum Guide defines the retrospective as the final event in each sprint, following the sprint review. While the review focuses on what the team built (product), the retrospective focuses on how the team worked (process).

The retrospective serves three purposes:

• Continuous improvement — Identify process changes that increase velocity, quality, or team satisfaction
• Psychological safety — Create space for honest feedback without fear of repercussions
• Team ownership — The team controls their own process; retrospectives are where they exercise that control

According to the Scrum Guide, retrospectives are timeboxed to a maximum of three hours for a one-month sprint. Most teams run 45-90 minute retrospectives for two-week sprints. The outcome is a list of 1-3 action items the team commits to implementing in the next sprint.

Sprint Retrospective vs Sprint Review#

Teams often confuse retrospectives with reviews because both happen at the end of the sprint. They serve different purposes and have different participants.

When to run retrospectives: After every sprint, without exception. Teams that skip retrospectives because "nothing went wrong" miss the opportunity to understand what went right so they can replicate it deliberately. For broader project review structures, see our guide on after action review templates.

The Retrospective Structure#

Every retrospective follows a five-phase structure, regardless of which template or format you choose. This framework was popularized by Esther Derby and Diana Larsen in their book Agile Retrospectives: Making Good Teams Great (2006).

1. Set the Stage (5 minutes)#

Create psychological safety by reminding the team that the retrospective is blame-free. Everyone contributed to both successes and problems. The goal is learning, not accountability.

Example opening:

"This retrospective is a safe space for honest feedback. We're here to improve
our process, not to assign blame. Leaders should share their mistakes first.
Everyone should challenge assumptions, including mine."

Use an icebreaker to warm up the conversation: "On a scale of 1-10, how do you feel this sprint went?" or "What's one word to describe this sprint?"

2. Gather Data (15 minutes)#

Collect observations about the sprint. Focus on facts: timelines, deliverables, blockers, team dynamics. Avoid interpreting or solving problems at this stage—just capture what happened.

Methods for gathering data:

• Silent writing (sticky notes or digital board)
• Round-robin sharing (everyone contributes one observation)
• Timeline mapping (plot key events chronologically)

3. Generate Insights (20 minutes)#

Analyze the data to identify patterns and root causes. Group similar observations into themes. Prioritize which themes to address first—teams cannot fix everything in one sprint.

Techniques for generating insights:

• Dot voting (each person votes on top 2-3 themes)
• 5 Whys (drill into root causes)
• Affinity mapping (group related observations)

4. Decide What to Do (15 minutes)#

Convert insights into actionable changes. Limit action items to 1-3 per sprint—teams that commit to 10 improvements accomplish zero. Assign owners and deadlines to each action.

Effective action items:

VAGUE: "Improve communication"
SPECIFIC: "Add a mid-sprint check-in on Wednesday at 2pm to surface blockers
early. Owner: Scrum Master. Start: Next sprint."

VAGUE: "Better code reviews"
SPECIFIC: "Require all PRs to have at least one approval before merging. Update
GitHub branch protection rules. Owner: Tech Lead. Due: Feb 28."

5. Close the Retrospective (5 minutes)#

Summarize key insights and action items. Express appreciation for the team's honesty. Remind the team that the Scrum Master will follow up on action items at the start of the next retrospective.

5 Proven Retrospective Formats#

Rotating formats keeps retrospectives fresh and prevents stale discussions.

1. Start Stop Continue#

The most popular retrospective format. Teams discuss what to start doing, stop doing, and continue doing in the next sprint.

When to use: First few sprints with a new team, or when you need a straightforward, low-pressure format. Start Stop Continue works well for teams new to retrospectives.

Template:

START: What should we start doing next sprint that we didn't do this sprint?
STOP: What should we stop doing next sprint that we did this sprint?
CONTINUE: What should we keep doing next sprint that worked well this sprint?

Example insights:

START: Daily standups at 9:30am instead of 10am to avoid calendar conflicts
STOP: Accepting vague acceptance criteria during sprint planning
CONTINUE: Pairing junior and senior developers on complex features

2. 4Ls (Loved, Learned, Lacked, Longed For)#

A balanced format that captures both positives and negatives across four categories.

When to use: Mid-project retrospectives when you want to capture learnings and unmet needs. The "Longed For" category surfaces unspoken team desires (better tools, clearer direction, more autonomy).

Template:

LOVED: What did we love about this sprint? What brought us joy or pride?
LEARNED: What did we learn—about the product, the process, or ourselves?
LACKED: What was missing? What did we need but didn't have?
LONGED FOR: What do we wish we had? What would make the next sprint better?

Example insights:

LOVED: Shipping the notification feature on Day 3—felt great to get early
feedback
LEARNED: SSL cert provisioning takes 7 days, not 2 days. Build in more buffer.
LACKED: Clear acceptance criteria on 3 of 8 user stories. We guessed what
"done" meant.
LONGED FOR: A staging environment that mirrors production so we catch bugs
before deploy

3. Mad Sad Glad#

An emotional check-in format that helps teams process feelings about the sprint. Mad Sad Glad is particularly effective after difficult sprints or contentious releases.

When to use: After high-stress sprints, failed releases, or when team morale feels low. This format validates emotions before jumping to solutions.

Template:

MAD: What frustrated you or stopped you from performing your best?
SAD: What disappointed you? What didn't meet your expectations?
GLAD: What went well? What were your favorite moments?

Example insights:

MAD: We deployed on Friday afternoon, then spent the weekend fixing production
bugs. We should have a "no Friday deploys" rule.
SAD: The Product Owner changed priorities mid-sprint without asking if we had
capacity. Two stories we started got abandoned.
GLAD: The team rallied to fix the payment bug in under 4 hours. Great
collaboration between backend and frontend.

4. Sailboat Retrospective#

A visual metaphor where the team is a sailboat navigating toward a goal. Identify what propels you forward (wind), what holds you back (anchors), and where you want to go (island).

When to use: When the team needs to reconnect with their sprint goal or product vision. The Sailboat format works well for teams that have lost sight of why they are doing the work.

Template:

ISLAND (Goal): Where are we headed? What's the sprint or product vision?
WIND (Propelling forces): What's helping us move forward? What's working well?
ANCHOR (Restraining forces): What's slowing us down or holding us back?
ROCKS (Risks): What obstacles or risks are ahead?

Example insights:

ISLAND: Launch MVP to 500 beta users by end of Q1
WIND: Product Owner is always available for questions. Fast feedback loop.
ANCHOR: CI/CD pipeline takes 45 minutes to run. Slows down iteration speed.
ROCKS: Third-party API we depend on has been down twice this month. Need a
backup plan.

5. DAKI (Drop, Add, Keep, Improve)#

A two-by-two grid that forces teams to make clear decisions about what to change and what to preserve.

When to use: When the team needs to make hard decisions about process changes. DAKI is more action-oriented than Start Stop Continue—it explicitly asks what to drop entirely.

Template:

DROP: What should we stop doing entirely? What's not adding value?
ADD: What new practices or tools should we introduce?
KEEP: What's working well that we should preserve?
IMPROVE: What's okay but could be better with small changes?

Example insights:

DROP: Weekly status report email that takes 2 hours to write and no one reads
ADD: Automated deployment to staging after every PR merge
KEEP: Pairing sessions on Thursdays for knowledge sharing
IMPROVE: Sprint planning—currently takes 3 hours, should be 2 hours max

Retrospective Facilitation Script#

For Scrum Masters facilitating a 60-minute retrospective:

OPENING (5 min): Create safety, run icebreaker ("On a scale of 1-10, how did
this sprint go?")

GATHER DATA (15 min): Use chosen format (Start Stop Continue, 4Ls, etc.).
Silent writing, then share.

GENERATE INSIGHTS (20 min): Group themes, dot vote on priority, discuss root
causes.

DECIDE WHAT TO DO (15 min): Convert insights into 1-3 specific actions with
owners and deadlines.

CLOSE (5 min): Summarize key learnings and action items. Send notes within
24 hours.

Best Practices for Effective Retrospectives#

Rotate formats every 2-3 sprints. Teams that use the same retrospective format for months report declining engagement and repetitive insights. Echometer's analysis of 22 retrospective templates shows that teams that rotate formats maintain higher participation and generate more actionable improvements.

Timebox ruthlessly. If discussion exceeds the allocated time, you are solving problems in real-time rather than reflecting. Retrospectives identify what to change; they do not redesign systems or build new tools. Save detailed problem-solving for separate working sessions.

Assign owners to every action item. Research from Atlassian on sprint retrospectives shows that action items without assigned owners have under 20% completion rates. "We should improve code reviews" accomplishes nothing. "Marcus to update PR template with review checklist by Feb 28" creates accountability.

Follow up on previous action items. Start each retrospective by reviewing last sprint's action items. Did we complete them? If not, why? Teams that skip this step see less than 30% action item completion. Teams that review completion rates at the start of each retro see over 70% completion.

Create psychological safety. Leaders must model vulnerability by sharing their own mistakes first. "I should have flagged the API dependency risk during planning" invites others to share execution gaps without fear. For techniques on building trust in team settings, see our stakeholder management guide.

Limit action items to 1-3 per sprint. Teams that commit to 10 improvements accomplish zero. One process change fully implemented beats five vague intentions.

No stakeholders or managers. When managers attend, team members self-censor. When stakeholders attend, the discussion shifts to product priorities (that belongs in the sprint review).

Measure retrospective effectiveness. Track action item completion rate, team satisfaction scores, and velocity trends. If retrospectives are working, you should see improvements over 3-5 sprints.

Common Retrospective Mistakes#

Running the same format every sprint. Echometer's study of agile retrospectives found that teams using the same format for more than 5 consecutive sprints report significantly lower engagement and fewer actionable insights.

No action items or vague action items. A retrospective that ends with "we should communicate better" has failed. Effective retrospectives produce specific, assigned, dated actions.

Skipping retrospectives when the sprint goes well. Understanding why something worked allows you to replicate it deliberately.

Letting discussions exceed timeboxes. Retrospectives identify what to fix; they do not fix it in real-time.

No follow-up on action items. Review action item completion at the start of every retro.

Leaders not participating or sharing. Leaders must model vulnerability by sharing their own mistakes first.

Turning retrospectives into blame sessions. Shift conversations from people to process.

Sprint Retrospective Example#

Here is a complete retrospective using the 4Ls format for a two-week sprint.

EVENT: Sprint 12 Retrospective | FORMAT: 4Ls | DURATION: 60 minutes

KEY INSIGHTS GATHERED:
LOVED: Shipped notifications feature on Day 3, got early user feedback
LEARNED: SSL cert provisioning takes 7 days, not 2 days we estimated
LACKED: Clear acceptance criteria on 3 user stories—we guessed what "done" meant
LONGED FOR: Staging environment that mirrors production

TOP THEME (8 votes): Unclear acceptance criteria causing rework

ROOT CAUSE: Product Owner writes stories just-in-time without refinement.
Developers do not push back during sprint planning.

ACTIONS:
1. Require Product Owner to refine top 3 stories before sprint planning with
   acceptance criteria. Owner: Product Owner. Start: Mar 3.
2. Add "Ask clarifying questions" step to sprint planning agenda. Owner: Scrum
   Master. Start: Mar 3.
3. Invite QA to mid-sprint check-in (Day 5) to review in-progress work. Owner:
   Scrum Master. Start: Mar 8.

Key Takeaways#

• Sprint retrospectives are the primary mechanism for continuous improvement in agile teams. Run them after every sprint without exception—teams that skip retros because "nothing went wrong" miss the opportunity to understand what went right.
• Rotate formats every 2-3 sprints to keep discussions fresh. The most effective formats are Start Stop Continue, 4Ls, Mad Sad Glad, Sailboat, and DAKI. Each serves different team contexts and moods.
• Limit action items to 1-3 per sprint with assigned owners and deadlines. Teams that commit to 10 improvements accomplish zero. One process change fully implemented beats five vague intentions.
• Create psychological safety by keeping stakeholders and managers out of retrospectives. Leaders must share their own mistakes first to model vulnerability and invite honest feedback.
• Follow up on action items at the start of every retrospective. Teams that review completion rates see over 70% action item completion. Teams that skip follow-up see under 30% completion.

For visualizing sprint timelines and retrospective insights in PowerPoint, Deckary provides sprint planning templates and agile timeline layouts—see our guide on making Gantt charts in PowerPoint. For structuring sprint ceremonies, see our complete Scrum framework guide.

Related Guides#

• Scrum Framework Guide — complete overview of Scrum roles, ceremonies, and artifacts
• After Action Review Template — structured reflection process for project teams
• Agile vs Waterfall — decision framework for methodology selection
• Progress Report Template — tracking accomplishments between sprint reviews
• RACI Matrix Examples — accountability framework for action item ownership

Sources#

• Echometer: 26 Fun & Fresh Agile Retrospective Templates in 2026
• Atlassian: Sprint Retrospective - How to Hold an Effective Meeting
• Parabol: 13 Effective Sprint Retrospective Techniques
• Aha!: Sprint Retrospective Templates - Options for Product Teams
• Scrum Guide