Scrum Retrospective Agenda Templates (45 / 60 / 90 minutes)

Why this agenda works

A good retro isn’t “talking about feelings for an hour.” It’s a short, honest inspection of how you worked, ending with a small set of changes you’ll actually try next Sprint. The agenda is the guardrail—your real job as facilitator is to protect focus, safety, and outcomes.

Below are three practical formats you can run tomorrow: 45 minutes (fast focus), 60 minutes (balanced), 90 minutes (deep dive)—each with outcomes, facilitation tips, and real-life examples.

45-minute retrospective (Fast Focus)

Use this when the team is overloaded, the Sprint was small, or you’re in “keep the engine running” mode. Aim for one strong action, not five weak ones.

Desired outcomes

• A shared view of what mattered this Sprint (not everything)
• 1–2 specific improvements with an owner and a “done” definition
• A realistic commitment the team believes in

1) 5 min — Set the stage: Sprint Goal + context

What you do: Re-state the Sprint Goal and whether it was met (yes/no/partially + why). Add context: unusual events, incidents, people on leave, big scope changes.

Facilitation tips: Keep it neutral: “Here’s what happened,” not “Who messed up.” If tension is high, use a quick check-in: “One word for how you’re arriving.”

Real-life example: “We didn’t fully hit the Sprint Goal because the payment gateway blocked requests for 2 days. That’s not a ‘developer problem’—it’s a system reliability constraint. Let’s treat it as a learning topic.”

2) 10 min — Gather data: highlights and friction points

What you do: Use a fast format: “Rose / Thorn” or “Liked / Learned / Lacked”. Ask everyone to add 1–2 notes silently (private reflection → faster honesty).

Facilitation tips: Timebox the sharing. You’re collecting signals, not analyzing yet. If the team goes vague (“communication was bad”), ask: “Where did it show up?”

• Prompt ideas: What helped us move fast?
• Prompt ideas: Where did work get stuck?
• Prompt ideas: What surprised us?

3) 15 min — Generate insights: themes and root causes

What you do: Cluster notes into 2–3 themes. For each theme, ask one root-cause question: “What made this likely?”

Facilitation tips: Don’t do a full 5 Whys for everything. Pick the most expensive pain. Convert judgment into curiosity: “What conditions created this?”

Real-life example: Theme: “Stories carry hidden work.” Root cause: The team started dev before acceptance criteria were clear, because refinement was skipped during a busy week. Insight: “We’re paying interest on unclear work.”

4) 10 min — Decide: 1–2 actionable improvements

What you do: Choose actions using a quick vote: each person gets 2 dots. Turn the winner into an experiment: “In the next Sprint, we will…”.

• Action quality checklist: Behavioral (what you’ll do differently)
• Action quality checklist: Small (fits the Sprint)
• Action quality checklist: Owned (someone drives it)
• Action quality checklist: Observable (you can tell if it happened)

Bad vs better action

• Bad action: “Improve communication.”
• Better: “Before dev starts, every story has AC + test notes; if not, it stays in refinement.”

5) 5 min — Close: commitment + owner

What you do: Name the owner(s) and define “done”. Quick confidence check (fist of five): if it’s low, shrink the action.

Real-life example: “Owner: Ayşe. Done means: 100% of sprint stories had a 10-minute pre-kickoff to confirm AC + dependencies.”

60-minute retrospective (Balanced Default)

This is the safest default for most Scrum teams. You can go deeper without losing momentum.

Desired outcomes

• 2–3 themes understood at “good enough” depth
• 1–3 improvements with clear owners and measures
• Team feels heard, not drained

1) 5 min — Set the stage

Sprint Goal recap + key events. Working agreement reminder: “Assume good intent; focus on the system.”

Tip: If you have a new team member, explain the purpose: “Retro is about improving how we work together, not blaming.”

2) 15 min — Gather data

Pick one data lens:

• Option A: Timeline — mark smooth days vs chaos days, incidents, scope changes, handoffs, review feedback, late surprises
• Option B: Start / Stop / Continue — fast and familiar, good for steady-state teams
• Tip: Silence first, then share. Silent writing increases signal and reduces anchoring.

3) 20 min — Generate insights

Cluster → pick top 2–3 themes. For each theme: “What pattern do we see?” “What’s the smallest lever we can pull?”

Real-life example: Theme: “QA bottleneck at the end.” Pattern: Testing starts too late; stories pile up. Lever: “Definition of Done includes test plan + early testing; we limit WIP in dev to avoid end-of-sprint traffic jams.”

4) 15 min — Decide actions

Turn insights into experiments. Use “If we…, then we expect…” framing.

• If we cap WIP at 2 per developer, then cycle time should drop and fewer items spill.
• If we do a 30-min mid-sprint review of progress vs goal, then we catch scope creep earlier.
• Tip: Don’t overload. A team can truly change 1–2 habits per Sprint. More becomes theater.

5) 5 min — Close and check-in

Owners + when you’ll review results (usually next retro).

Ask: “What’s one thing you appreciate about the team this Sprint?” (Optional, but powerful when morale is low.)

90-minute retrospective (Deep Dive)

Use this when there’s high conflict, major incidents, recurring failures, or a big system change. The goal is clarity + repair + one meaningful improvement, not a marathon.

Desired outcomes

• Shared understanding of the real problem (often not what people first blame)
• Clear decision(s) about next steps and how you’ll work together
• Emotional “pressure release” without turning into a complaint session

1) 10 min — Set the stage

Purpose: “We’re here to learn and improve the system.”

Safety: remind confidentiality and respect.

If conflict exists, name it gently: “There’s been tension around X. We’ll handle it constructively.”

Tip: Consider a “working agreement reset” for 2 minutes: No interrupting, Speak from your experience, We challenge ideas, not people.

2) 25 min — Gather data

Choose a method that suits the situation:

• For incidents: Incident timeline + impact + decisions made; What signals did we miss? What slowed recovery?
• For conflict: Facts / Stories / Feelings / Needs mapping

Real-life example

After a production outage, the team blames “bad code.” The timeline shows: missing alerts + unclear ownership + no rollback runbook. The fix isn’t “code better”—it’s “operate better.”

3) 30 min — Generate insights

Pick the top 1–2 topics and go deeper: 5 Whys (careful: don’t weaponize it); Fishbone categories: People / Process / Tech / External constraints; “Where do we keep paying the same cost?”

Tip: If discussion becomes circular, interrupt with structure: “Let’s write down hypotheses, then pick one to test.”

4) 20 min — Decide actions

For deep-dive retros, actions often include process guardrails, technical improvements, and working agreements.

Make it concrete: Owner + due date + measurable signal of success.

Example: “Add rollback playbook and run a 20-min drill next Sprint.”

5) 5 min — Close

Summarize: “What did we learn? What will we try?”

Quick check: “Anything unsaid that would block us from moving on?”

Facilitation notes (that make these agendas actually work)

• Protect “one conversation at a time.” If two people argue, stop and reframe: “What’s the underlying need here?” “What decision are we trying to make?”
• Keep actions small and observable. If an action can’t be verified, it won’t happen. Add a “how we’ll know” line.
• Don’t let the retro become status or solution-design. Retro isn’t planning the perfect system. It’s choosing the next improvement.
• Close the loop next Sprint: Start the next retro with “Last time we tried X. Did it help?”

Quick Copy-Paste Version (Agendas Only)