During the Daily Scrum, a Scrum Master notices the Developers haven't discussed the firmware flashing task that's most at risk of missing the Sprint Goal, so the Scrum Master decides who should pick it up next. Was this an appropriate action?
Select an answer to reveal the explanation.
Short Explanation
Even when the Scrum Master can see the danger coming, the fix still has to come from the Developers themselves — otherwise the meeting quietly turns into someone else's status update. Noticing the risk out loud is fair game; picking who does what next isn't.
Full Explanation
The Daily Scrum is a Developers-only inspect-and-adapt event: they create the plan for the next day of work and organize the conversation to serve that purpose, and the Scrum Master's accountability is limited to ensuring the event happens and is understood, not running or controlling its content. Deciding which Developer should pick up an at-risk task crosses from supporting the event into directing the Developers' work, which conflicts with self-management even when the underlying concern — a Sprint Goal at risk — is legitimate. The first wrong option conflates "keeping the event healthy" with "controlling its outcomes," which are not the same responsibility. The second wrong option is closer but still wrong: while any Developer might reasonably flag risk and reassign work among themselves, the question specifically describes the Scrum Master making that call, and the correct framing is that this decision sits with the Developers regardless of who raises the concern. The Scrum Master attending the Daily Scrum is not itself a problem — the Guide permits attendance as long as the event stays Developer-led — so the claim that they shouldn't have been there misdiagnoses the issue. A useful check: if a Scrum Master's contribution during the Daily Scrum could be rephrased as a question surfacing risk rather than a decision resolving it, that's usually the safer form.