5 exercises — open, facilitate, and close a blameless sprint retrospective in English.
0 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Context: You're reviewing a pull request for a new feature. A developer has included extensive comments on the code, pointing out potential performance bottlenecks and suggesting optimizations. How should you respond to this feedback in a constructive way?
The correct response demonstrates a willingness to learn and collaborate. Saying 'This is terrible code!' is overly critical and unproductive. Suggesting a discussion shows respect for the developer's expertise while acknowledging the potential improvements. Options C and D are dismissive or unhelpful.
7 / 10
Context: During a Slack channel discussion about a recently completed API endpoint, a developer writes: 'Just deployed the update. Response time is still sluggish – maybe we should look into caching?' How should you respond to this initial observation?
This question focuses on initial observations and investigation. Simply stating 'Caching is always the solution!' is a common mistake. Suggesting investigation into latency metrics demonstrates a systematic approach to troubleshooting. Options C and D are dismissive or inaccurate.
8 / 10
Context: You're facilitating a sprint demo. A team member presents the new feature they've been working on. After the demo, another team member says, 'I think we could have made this more user-friendly if we had included an error message when the user enters invalid data.' How should you handle this feedback during the demo?
The best response acknowledges the feedback while maintaining a positive and forward-looking tone. Suggesting adding it to the backlog demonstrates that the team is open to future improvements. Options B, C, and D shift blame or minimize the importance of user experience.
9 / 10
Context: During a standup meeting, a developer says, 'I'm blocked on getting access to the staging environment.' How should you respond to this statement from the Scrum Master's perspective?
As Scrum Master, your role is to remove impediments. Acknowledging the blocker and offering to investigate demonstrates proactive leadership. Simply telling the developer to 'ask DevOps for help!' doesn't address the underlying problem. Options C and D shift responsibility or blame.
10 / 10
Context: The team has just finished a sprint retrospective. You're summarizing the key takeaways. Which of the following statements is the MOST effective closing statement?
The most effective closing statement focuses on accountability and next steps. Scheduling a follow-up meeting demonstrates commitment to implementing the action items. Options C and D are vague or unproductive. Saying 'Great job, everyone!' is generic and doesn't drive concrete action.
What will I learn from the "Sprint Retrospective Phrases — Sprint Demo Exercises" exercise?
Practice sprint retrospective facilitation phrases: 'what went well', 'what could be improved', 'action items', running a blameless retro, and closing with accountable commitments. 5 advanced exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Sprint Demo & Releases exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss sprint demo & releases topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Sprint Demo & Releases exercises?
See the full Sprint Demo & Releases exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.