During a Sprint Retrospective, a home-robot company's firmware team spends the whole session identifying that a slow flash-cycle test rig kept blocking integration work all Sprint. What is the Retrospective's purpose in this situation, according to the Scrum Guide?
Select an answer to reveal the explanation.
Short Explanation
Picture the Retrospective as the team's own maintenance check on itself — not on any one person. Finding that the test rig slowed everyone down is exactly the kind of thing it's for: name what happened, then figure out what to actually change. It's about the system the team works in, not a verdict on who's at fault.
Full Explanation
The Scrum Guide states the Sprint Retrospective's purpose is for the Scrum Team to inspect how the last Sprint went with regard to individuals, interactions, processes, tools, and its Definition of Done, and to plan ways to increase quality and effectiveness. A slow test rig is a tools problem — precisely one of the dimensions the Guide names. Assigning blame to an individual misreads the event: Scrum treats problems as things the whole team inspects and adapts around, not as grounds for finding fault, and singling out a person undermines the psychological safety the Retrospective depends on. Automatically rolling unfinished Sprint Backlog items forward is not what a Retrospective does either — the Sprint Backlog is not carried over as a rule, and any decision about unfinished work happens through Product Backlog refinement and future Sprint Planning, not the Retrospective's inspect-and-adapt conversation. Escalating straight to management before the team discusses it skips the team's own agency — the Scrum Team, including the Scrum Master, owns identifying and often resolving impediments itself. A concrete check: did the Retrospective produce at least one actionable improvement the team can try next Sprint, such as reserving rig time earlier or building a second rig?