5 exercises — open, facilitate, and close a blameless sprint retrospective in English.
0 / 5 completed
1 / 5
You are opening a sprint retrospective as the Scrum Master. The team had a difficult sprint with a production incident. Which opening sets the right tone for a blameless retro?
Option B establishes the blameless retrospective contract — the foundation of a psychologically safe retro.
Elements of a good retro opening: 1. "Safe space" — explicit permission to speak honestly 2. "Systems and processes, not people" — the blameless principle stated clearly 3. "Everything said here stays in this room" — confidentiality encourages candour 4. "2–3 concrete action items" — sets outcome expectations; avoids meandering discussions 5. "Start with what went well" — signals positive framing before discussing problems
The blameless retro principle: Blameless retrospectives assume that people made reasonable decisions given the information they had at the time. When things go wrong, we look for system failures, process gaps, and communication breakdowns — not culprits.
Why "who is responsible" kills retros: Once blame enters a retro, people become defensive. They stop sharing information that might implicate them. The retrospective stops producing useful learning.
Prime Directive (Norm Kerth): "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
2 / 5
During the "What went well" round, a team member says "I think the daily standups were really efficient this sprint." As facilitator, how do you respond?
"Can you say more about that — what specifically..." is the retro facilitator's deepening question.
Why specificity matters in "What went well": Vague positives ("it was good") cannot be reproduced. If you want to preserve a practice, you need to understand exactly what made it work — so you can protect that element even when circumstances change.
What "efficient standups" might reveal: • "We used a shared doc instead of going person by person" • "We moved standup to 9:30 instead of 9:00 and people showed up prepared" • "The PO wasn't in the room, so we stayed technical"
Each of these is a specific, preservable practice. "It was efficient" is not.
Facilitator deepening questions: • "Can you say more about what specifically made that work?" • "What would we need to do to make that happen again next sprint?" • "Is there a specific moment you're thinking of?" • "What would it look like if we lost that?"
Why "I agree!" fails as a facilitator: Facilitators should be neutral. Expressing personal opinions shifts the group's attention toward what the facilitator thinks, suppressing dissenting views.
3 / 5
A team member raises a recurring problem: "The deployment process is still too manual — we keep having to ping DevOps every time." Three other team members nod. How do you transition this into an action item?
Option C demonstrates the retro action item creation pattern — the most important skill in retrospective facilitation.
Action item formula: [Validate the pain] → [Confirm shared ownership] → [Assign a specific owner] → [Define done]
Breaking down Option C: 1. "Clear pain point" — validates the concern without judgment 2. "Others share it" — references the visible consensus (nodding) to create momentum 3. "Who would own..." — action items without owners do not happen 4. "What would 'done' look like" — defines the success criterion so progress can be tracked
Why "we've discussed this before" kills retros: If a problem keeps appearing in retros without being resolved, that itself is the problem — the process for converting retro feedback into action is broken. Address the recurrence: "This has come up before — why wasn't it resolved? What would make this time different?"
SMART action items from retros: • Specific: what exactly will be done? • Measurable: how will we know it's done? • Assignable: one person owns it (not "the team") • Relevant: connected to the pain described • Time-bound: deadline before next retro
4 / 5
The retro discussion has drifted into a 15-minute argument about whether the team should switch from Jira to Linear. You need to refocus without dismissing the topic. What do you say?
Option B uses the parking lot technique — the standard facilitator tool for managing important but off-topic discussions.
The parking lot: A visible space (whiteboard, sticky note, shared doc) where topics are captured so the group can see they're not being dismissed — just deferred. The key is that items in the parking lot get a specific follow-up, not just "we'll think about it."
What makes Option B effective: 1. "Parking lot" — named technique; signals you have a process for this 2. "Worth a dedicated discussion" — validates the importance of the topic 3. "Too big to resolve here" — honest about why you're deferring 4. "I'll schedule a separate meeting" — concrete commitment, not just dismissal 5. "Can we come back to..." — polite redirect with a specific destination
Facilitator redirect phrases: • "Let me park that — it deserves more time than we have here." • "That's a big topic — can we add it to the parking lot and come back?" • "I want to make sure we get to action items — can we hold that for a follow-up?" • "Great discussion — let's capture that and schedule time to go deeper."
5 / 5
You are closing the retrospective. The team agreed on three action items. Which closing statement is most effective?
Option C is the complete retrospective closing statement.
Retro closing formula: 1. Read back each action item — with owner and deadline — out loud 2. State where they'll be tracked — "I'll add them to the team board" 3. Commit to a follow-up — "follow up at next sprint planning" 4. Set next retro expectations — "same time next sprint" 5. Final open floor — "any final thoughts?" — closes the loop on anything unspoken
Why reading action items aloud matters: People who verbally commit to something in front of peers are significantly more likely to follow through than people who are passively added to a ticket. The public read-back creates social accountability.
Why "check the board" fails: It assumes people will check — they often don't. The facilitator's job is to close the session with clarity, not to delegate clarity to a board nobody watches.
Follow-up pattern: At the start of the next retro, revisit the previous retro's action items before opening new discussion: "We had three action items last sprint — let's check in on each one." This is the most important factor in making retrospectives feel worth attending.