🪞 Retrospective Formats
Master the facilitation language for Start/Stop/Continue, 4Ls, and sailboat retrospectives. Intermediate
0 / 25 completed
1 / 25
During a Start / Stop / Continue retrospective, a developer says:
"I think we should START doing a short async update in our team Slack channel 30 minutes before standup — just a few bullet points on what you did and what you plan. That way the standup itself can focus entirely on blockers."
Which retrospective category does this suggestion correctly belong to, and why?
The Start / Stop / Continue format sorts team improvements into three buckets:
| Category | Definition | Example signal |
|---|---|---|
| Start | New practice the team should adopt — not yet part of any routine | "We should START doing X" |
| Stop | Existing practice that is creating friction or waste and should be discontinued | "We should STOP doing Y" |
| Continue | Practice that is working well and the team wants to deliberately keep doing | "We should CONTINUE doing Z" |
The async pre-standup update is a new practice — the team does not currently do it. The team member explicitly says "we should START," which is the correct signal. It does not stop the standup; it adds a complementary channel. A valid Start item must be actionable and specific enough to try next sprint.
2 / 25
The team is closing a retrospective. The Scrum Master says: "Let's check our action items before we finish. Each one should be specific, assigned to someone, and time-boxed."
Which of the following retrospective action items is correctly formulated?
A well-formed retro action item follows the SMART pattern — it must be Specific, Measurable, Achievable, Relevant, and Time-bound. Let's evaluate each option:
| Option | Problem |
|---|---|
| A — "communicate more clearly" | Vague: no specific action, not assigned, not measurable, no deadline |
| B — "everyone should…" | Not assigned to a named person — "everyone" means no one is accountable |
| C — "at some point…" | No deadline — "next few sprints" is indefinite and will never be reviewed |
| D — "Ana will… by end of Sprint 18" | ✓ Specific action, single owner, verifiable output, clear deadline |
The three most common retro action item failures are: (1) no named owner, (2) no concrete deadline, and (3) no observable outcome. Vague commitments feel productive in the moment but are forgotten by the next sprint.
3 / 25
The team is running a 4Ls retrospective (Liked, Learned, Lacked, Longed For). A developer adds a sticky note that says:
"I LEARNED that our deployment pipeline has a manual approval step that most of the team didn't even know existed — we discovered it only when a release was blocked for 4 hours waiting for sign-off."
Which of the 4Ls does this note correctly belong to?
The 4Ls format gives each insight a clear home based on its nature:
| Category | What belongs here | Example |
|---|---|---|
| Liked | Things that went well; positive experiences worth acknowledging | "I liked our pair programming sessions this sprint" |
| Learned | New knowledge or insights gained during the sprint | "I learned the deployment pipeline has a manual approval step" |
| Lacked | Missing tools, information, skills, or support that slowed the team | "We lacked clear documentation on the approval process" |
| Longed For | Desired improvements or capabilities not yet available | "I long for an automated approval trigger in the pipeline" |
The key word in the sticky note is "I LEARNED" — this explicitly signals new knowledge acquired during the sprint. Note that this same incident could also generate a Lacked note ("we lacked pipeline documentation") and a Longed For note ("we want automated approvals") — those would be separate cards.
4 / 25
The Scrum Master is facilitating a sailboat retrospective. The team has placed the boat in the centre of the board and drawn different elements around it. The facilitator asks the team to add sticky notes to the anchors beneath the boat.
What do the anchors represent in a sailboat retrospective?
The sailboat retrospective uses nautical metaphors to categorise team feedback:
| Metaphor | Represents |
|---|---|
| ⛵ The sailboat | The team itself |
| ☀️ The island / destination | The team's goal or product vision |
| 💨 The wind (sails) | Things helping the team move forward — tailwinds, strengths |
| ⚓ Anchors | Things slowing the team down — impediments, friction, drag |
| 🪨 Rocks (some variants) | Risks and hazards ahead |
Anchors (Option C) are current impediments — slow CI pipelines, unclear requirements, frequent context-switching, missing tooling. Option A (future risks) maps to rocks, not anchors. Option B (goals) maps to the island destination. The anchor metaphor is physical: an anchor pulls the boat back, preventing forward motion.
5 / 25
At the end of a sprint retrospective, four action items are proposed. The Scrum Master checks each one against the SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound).
Which action item is correctly formulated as a SMART improvement?
Let's evaluate each option against the SMART criteria:
| Option | S | M | A | R | T |
|---|---|---|---|---|---|
| A — Hiroshi, CI coverage report, Sprint 16 | ✓ | ✓ (report exists) | ✓ | ✓ | ✓ (last day S16) |
| B — "the team should improve coverage" | ✗ vague | ✗ no number | ? | ✓ | ✗ no deadline |
| C — "someone will look into…" | ✗ vague | ✗ | ? | ✓ | ✗ no deadline |
| D — "we will all be more careful" | ✗ | ✗ | ✗ | ✓ | ✗ |
A SMART retro action item must have one named owner, a concrete deliverable, and a specific deadline. "We will all" and "someone will" are accountability traps — when everyone is responsible, no one is.
6 / 25
During a sprint retrospective, the team discusses recent challenges with their CI/CD pipeline. One developer suggests: 'We should add automated tests to our integration stage, specifically focusing on API endpoints. This will reduce the number of manual deployments and prevent regressions.' Which statement best reflects the purpose of this suggestion within a retrospective format?
This suggestion is correct because retrospectives are about identifying *problems* and exploring *solutions*. The developer isn't just stating a desire for automation; they're proposing an action to mitigate a potential risk. Options A and C are too broad or simply restate the status quo, while option D incorrectly limits the retrospective's scope. Identifying specific areas needing improvement (like API tests) is a key element of driving positive change.
7 / 25
PR Description:
Subject: Fix: Prevent NullPointerException in UserProfileService when retrieving inactive users.
Details:
This PR addresses a critical bug where attempting to retrieve inactive user profiles could result in a NullPointerException. The issue was caused by a race condition during database queries, leading to inconsistent data states. The fix involves adding a check for null before accessing the user's name property. Unit tests have been added to verify this change.
@john.doe @jane.smith Please review.The correct answer highlights that the PR description is deficient because it lacks sufficient technical detail. A good PR description should explain *why* the problem occurred (the race condition), how the fix addresses it (null check), and ideally, mention the testing performed. The other options either overstate the quality or miss these crucial elements – a developer needs enough information to confidently review the code and understand its implications.
8 / 25
During a sprint retrospective, the team is discussing impediments to their code deployments. Sarah, a senior developer, shares this comment in the Slack channel: 'Okay, so I'm blocked because the automated tests for the new authentication service haven't been updated to cover the OAuth flow. It's taking me ages to get them running.' The Scrum Master asks the team to identify an action item based on Sarah's statement. Which of the following best represents a suitable action item for the retrospective?
The correct answer focuses on a concrete, actionable step directly addressing Sarah's stated impediment. Options A and C are too broad and lack specifics – they don't assign responsibility or set a timeframe. Option B is the most effective because it clearly assigns ownership (David) and establishes a realistic deadline (2 days), aligning with agile principles of iterative improvements. This demonstrates how retrospectives should move beyond general discussions towards tangible solutions.
9 / 25
The team is running a retrospective focused on improving their communication. During the discussion, a developer suggests: 'Let's create a daily stand-up summary in Jira with just the key decisions and action items from each stand-up – no more than 30 seconds per item.' Which of the following best represents a suitable outcome or action item for this suggestion within a retrospective format?
This option correctly identifies a proactive approach to streamlining communication. The core purpose of retrospectives is to identify areas for improvement, and reducing information overload during daily stand-ups aligns with that goal. The other options misinterpret the retrospective's objective – it's not simply about documenting decisions but actively improving the process itself.
10 / 25
The team is running a retrospective after completing a challenging sprint. During the discussion of potential improvements to their workflow, David suggests: 'We need to implement a daily 'quick sync' meeting with the QA team – just 15 minutes to quickly align on any blocking issues and prioritize testing.' The Scrum Master wants to ensure this suggestion aligns with the principles of Agile retrospectives. Which of the following best represents an appropriate action item for the retrospective, considering the goal is continuous improvement?
Option A: Assign David the task of scheduling a weekly meeting with QA.
Option B: Create an action item to explore different tools for collaborative bug tracking and reporting, incorporating feedback from both development and QA teams.
Option C: Add 'quick sync' meetings to the sprint backlog as recurring tasks with pre-defined time slots.
Option D: Request a team vote on whether or not David's suggestion should be implemented.
The correct answer (Option B) aligns best with the purpose of a retrospective – identifying areas for *improvement* rather than simply implementing new processes. Adding a recurring task without further discussion risks treating the suggestion as a fixed requirement instead of an outcome derived from the team's reflection. Options A and C are too prescriptive, and Option D doesn't facilitate the necessary analysis and consensus-building that retrospectives aim to achieve.
11 / 25
During a sprint retrospective, the team discusses recent challenges with their CI/CD pipeline. One developer suggests: 'We should add automated tests to our integration stage, specifically focusing on API endpoints. This will reduce the number of manual deployments and prevent regressions.' Which statement best reflects the purpose of this suggestion within a retrospective format?
This suggestion is correct because retrospectives are about identifying *problems* and exploring *solutions*. The developer isn't just stating a desire for automation; they're proposing an action to mitigate a potential risk. Options A and C are too broad or simply restate the status quo, while option D incorrectly limits the retrospective's scope. Identifying specific areas needing improvement (like API tests) is a key element of driving positive change.
12 / 25
PR Description:
Subject: Fix: Prevent NullPointerException in UserProfileService when retrieving inactive users.
Details:
This PR addresses a critical bug where attempting to retrieve inactive user profiles could result in a NullPointerException. The issue was caused by a race condition during database queries, leading to inconsistent data states. The fix involves adding a check for null before accessing the user's name property. Unit tests have been added to verify this change.
@john.doe @jane.smith Please review.The correct answer highlights that the PR description is deficient because it lacks sufficient technical detail. A good PR description should explain *why* the problem occurred (the race condition), how the fix addresses it (null check), and ideally, mention the testing performed. The other options either overstate the quality or miss these crucial elements – a developer needs enough information to confidently review the code and understand its implications.
13 / 25
During a sprint retrospective, the team is discussing impediments to their code deployments. Sarah, a senior developer, shares this comment in the Slack channel: 'Okay, so I'm blocked because the automated tests for the new authentication service haven't been updated to cover the OAuth flow. It's taking me ages to get them running.' The Scrum Master asks the team to identify an action item based on Sarah's statement. Which of the following best represents a suitable action item for the retrospective?
The correct answer focuses on a concrete, actionable step directly addressing Sarah's stated impediment. Options A and C are too broad and lack specifics – they don't assign responsibility or set a timeframe. Option B is the most effective because it clearly assigns ownership (David) and establishes a realistic deadline (2 days), aligning with agile principles of iterative improvements. This demonstrates how retrospectives should move beyond general discussions towards tangible solutions.
14 / 25
The team is running a retrospective focused on improving their communication. During the discussion, a developer suggests: 'Let's create a daily stand-up summary in Jira with just the key decisions and action items from each stand-up – no more than 30 seconds per item.' Which of the following best represents a suitable outcome or action item for this suggestion within a retrospective format?
This option correctly identifies a proactive approach to streamlining communication. The core purpose of retrospectives is to identify areas for improvement, and reducing information overload during daily stand-ups aligns with that goal. The other options misinterpret the retrospective's objective – it's not simply about documenting decisions but actively improving the process itself.
15 / 25
The team is running a retrospective after completing a challenging sprint. During the discussion of potential improvements to their workflow, David suggests: 'We need to implement a daily 'quick sync' meeting with the QA team – just 15 minutes to quickly align on any blocking issues and prioritize testing.' The Scrum Master wants to ensure this suggestion aligns with the principles of Agile retrospectives. Which of the following best represents an appropriate action item for the retrospective, considering the goal is continuous improvement?
Option A: Assign David the task of scheduling a weekly meeting with QA.
Option B: Create an action item to explore different tools for collaborative bug tracking and reporting, incorporating feedback from both development and QA teams.
Option C: Add 'quick sync' meetings to the sprint backlog as recurring tasks with pre-defined time slots.
Option D: Request a team vote on whether or not David's suggestion should be implemented.
The correct answer (Option B) aligns best with the purpose of a retrospective – identifying areas for *improvement* rather than simply implementing new processes. Adding a recurring task without further discussion risks treating the suggestion as a fixed requirement instead of an outcome derived from the team's reflection. Options A and C are too prescriptive, and Option D doesn't facilitate the necessary analysis and consensus-building that retrospectives aim to achieve.
16 / 25
During a sprint retrospective, the team discusses recent challenges with their CI/CD pipeline. One developer suggests: 'We should add automated tests to our integration stage, specifically focusing on API endpoints. This will reduce the number of manual deployments and prevent regressions.' Which statement best reflects the purpose of this suggestion within a retrospective format?
This suggestion is correct because retrospectives are about identifying *problems* and exploring *solutions*. The developer isn't just stating a desire for automation; they're proposing an action to mitigate a potential risk. Options A and C are too broad or simply restate the status quo, while option D incorrectly limits the retrospective's scope. Identifying specific areas needing improvement (like API tests) is a key element of driving positive change.
17 / 25
PR Description:
Subject: Fix: Prevent NullPointerException in UserProfileService when retrieving inactive users.
Details:
This PR addresses a critical bug where attempting to retrieve inactive user profiles could result in a NullPointerException. The issue was caused by a race condition during database queries, leading to inconsistent data states. The fix involves adding a check for null before accessing the user's name property. Unit tests have been added to verify this change.
@john.doe @jane.smith Please review.The correct answer highlights that the PR description is deficient because it lacks sufficient technical detail. A good PR description should explain *why* the problem occurred (the race condition), how the fix addresses it (null check), and ideally, mention the testing performed. The other options either overstate the quality or miss these crucial elements – a developer needs enough information to confidently review the code and understand its implications.
18 / 25
During a sprint retrospective, the team is discussing impediments to their code deployments. Sarah, a senior developer, shares this comment in the Slack channel: 'Okay, so I'm blocked because the automated tests for the new authentication service haven't been updated to cover the OAuth flow. It's taking me ages to get them running.' The Scrum Master asks the team to identify an action item based on Sarah's statement. Which of the following best represents a suitable action item for the retrospective?
The correct answer focuses on a concrete, actionable step directly addressing Sarah's stated impediment. Options A and C are too broad and lack specifics – they don't assign responsibility or set a timeframe. Option B is the most effective because it clearly assigns ownership (David) and establishes a realistic deadline (2 days), aligning with agile principles of iterative improvements. This demonstrates how retrospectives should move beyond general discussions towards tangible solutions.
19 / 25
The team is running a retrospective focused on improving their communication. During the discussion, a developer suggests: 'Let's create a daily stand-up summary in Jira with just the key decisions and action items from each stand-up – no more than 30 seconds per item.' Which of the following best represents a suitable outcome or action item for this suggestion within a retrospective format?
This option correctly identifies a proactive approach to streamlining communication. The core purpose of retrospectives is to identify areas for improvement, and reducing information overload during daily stand-ups aligns with that goal. The other options misinterpret the retrospective's objective – it's not simply about documenting decisions but actively improving the process itself.
20 / 25
The team is running a retrospective after completing a challenging sprint. During the discussion of potential improvements to their workflow, David suggests: 'We need to implement a daily 'quick sync' meeting with the QA team – just 15 minutes to quickly align on any blocking issues and prioritize testing.' The Scrum Master wants to ensure this suggestion aligns with the principles of Agile retrospectives. Which of the following best represents an appropriate action item for the retrospective, considering the goal is continuous improvement?
Option A: Assign David the task of scheduling a weekly meeting with QA.
Option B: Create an action item to explore different tools for collaborative bug tracking and reporting, incorporating feedback from both development and QA teams.
Option C: Add 'quick sync' meetings to the sprint backlog as recurring tasks with pre-defined time slots.
Option D: Request a team vote on whether or not David's suggestion should be implemented.
The correct answer (Option B) aligns best with the purpose of a retrospective – identifying areas for *improvement* rather than simply implementing new processes. Adding a recurring task without further discussion risks treating the suggestion as a fixed requirement instead of an outcome derived from the team's reflection. Options A and C are too prescriptive, and Option D doesn't facilitate the necessary analysis and consensus-building that retrospectives aim to achieve.
21 / 25
During a sprint retrospective, the team discusses recent challenges with their CI/CD pipeline. One developer suggests: 'We should add automated tests to our integration stage, specifically focusing on API endpoints. This will reduce the number of manual deployments and prevent regressions.' Which statement best reflects the purpose of this suggestion within a retrospective format?
This suggestion is correct because retrospectives are about identifying *problems* and exploring *solutions*. The developer isn't just stating a desire for automation; they're proposing an action to mitigate a potential risk. Options A and C are too broad or simply restate the status quo, while option D incorrectly limits the retrospective's scope. Identifying specific areas needing improvement (like API tests) is a key element of driving positive change.
22 / 25
PR Description:
Subject: Fix: Prevent NullPointerException in UserProfileService when retrieving inactive users.
Details:
This PR addresses a critical bug where attempting to retrieve inactive user profiles could result in a NullPointerException. The issue was caused by a race condition during database queries, leading to inconsistent data states. The fix involves adding a check for null before accessing the user's name property. Unit tests have been added to verify this change.
@john.doe @jane.smith Please review.The correct answer highlights that the PR description is deficient because it lacks sufficient technical detail. A good PR description should explain *why* the problem occurred (the race condition), how the fix addresses it (null check), and ideally, mention the testing performed. The other options either overstate the quality or miss these crucial elements – a developer needs enough information to confidently review the code and understand its implications.
23 / 25
During a sprint retrospective, the team is discussing impediments to their code deployments. Sarah, a senior developer, shares this comment in the Slack channel: 'Okay, so I'm blocked because the automated tests for the new authentication service haven't been updated to cover the OAuth flow. It's taking me ages to get them running.' The Scrum Master asks the team to identify an action item based on Sarah's statement. Which of the following best represents a suitable action item for the retrospective?
The correct answer focuses on a concrete, actionable step directly addressing Sarah's stated impediment. Options A and C are too broad and lack specifics – they don't assign responsibility or set a timeframe. Option B is the most effective because it clearly assigns ownership (David) and establishes a realistic deadline (2 days), aligning with agile principles of iterative improvements. This demonstrates how retrospectives should move beyond general discussions towards tangible solutions.
24 / 25
The team is running a retrospective focused on improving their communication. During the discussion, a developer suggests: 'Let's create a daily stand-up summary in Jira with just the key decisions and action items from each stand-up – no more than 30 seconds per item.' Which of the following best represents a suitable outcome or action item for this suggestion within a retrospective format?
This option correctly identifies a proactive approach to streamlining communication. The core purpose of retrospectives is to identify areas for improvement, and reducing information overload during daily stand-ups aligns with that goal. The other options misinterpret the retrospective's objective – it's not simply about documenting decisions but actively improving the process itself.
25 / 25
The team is running a retrospective after completing a challenging sprint. During the discussion of potential improvements to their workflow, David suggests: 'We need to implement a daily 'quick sync' meeting with the QA team – just 15 minutes to quickly align on any blocking issues and prioritize testing.' The Scrum Master wants to ensure this suggestion aligns with the principles of Agile retrospectives. Which of the following best represents an appropriate action item for the retrospective, considering the goal is continuous improvement?
Option A: Assign David the task of scheduling a weekly meeting with QA.
Option B: Create an action item to explore different tools for collaborative bug tracking and reporting, incorporating feedback from both development and QA teams.
Option C: Add 'quick sync' meetings to the sprint backlog as recurring tasks with pre-defined time slots.
Option D: Request a team vote on whether or not David's suggestion should be implemented.
The correct answer (Option B) aligns best with the purpose of a retrospective – identifying areas for *improvement* rather than simply implementing new processes. Adding a recurring task without further discussion risks treating the suggestion as a fixed requirement instead of an outcome derived from the team's reflection. Options A and C are too prescriptive, and Option D doesn't facilitate the necessary analysis and consensus-building that retrospectives aim to achieve.
Frequently Asked Questions
What will I practice in "Retrospective Formats | Agile & Scrum Exercises"?
This is an Agile & Scrum exercise set. It walks through 25 scenario-based multiple-choice questions built around real usage of Agile & Scrum terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 25 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Agile & Scrum vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Agile & Scrum exercises?
See the Agile & Scrum exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Agile & Scrum vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.