Master the terminology behind running effective sprint retrospectives.
0 / 5 completed
1 / 5
At standup, a dev mentions the team will discuss what went well and what didn't at the end of the sprint. What meeting are they referring to?
The sprint retrospective (retro) is a recurring meeting at the end of each sprint where the team reflects on process, collaboration, and outcomes to identify improvements. Unlike a postmortem, it isn't triggered by an incident but happens on a regular cadence. It focuses on how the team works, not just what was shipped.
2 / 5
During a retro, the facilitator groups feedback into columns for what to keep, stop, and start doing. What format is this?
The start-stop-continue format structures retro feedback into three categories: new practices to start, unhelpful ones to stop, and effective ones to continue. This simple framework makes it easy for participants to contribute actionable feedback. It's one of several common retro facilitation templates.
3 / 5
In a code review of the team's retro notes, a dev sees follow-up improvements assigned to specific owners. What are these called?
Retro action items are the concrete process improvements identified during the retrospective, ideally assigned an owner and tracked to completion. Without this, retros risk becoming a venting session with no lasting change. Turning insights into tracked action items is what makes retros effective over time.
4 / 5
An incident report shows the same process issue was raised in three consecutive retros with no change. What does this indicate?
A recurring complaint across multiple retros without resolution usually means action items from prior retros weren't actually implemented or tracked. This erodes trust in the retro process, since raising issues starts to feel pointless. Closing the loop on prior action items should be a standing agenda item.
5 / 5
During a PR review, a teammate asks how a retro differs from a postmortem. What is the key distinction?
A retro is a regularly scheduled reflection on the team's overall process and collaboration, while a postmortem is specifically triggered by an incident to analyze what went wrong technically. Both aim at continuous improvement but differ in cadence and trigger. Confusing the two can lead to holding the wrong kind of meeting for the situation.