How do you fix a Daily Scrum that runs too long?

WHAT THIS TESTS: This question tests your understanding of the Daily Scrum's specific purpose: to inspect progress toward the Sprint Goal and create an actionable plan for the next 24 hours. It is not a status report or a problem-solving session. The interviewer is looking for a Scrum Master who can coach and facilitate the team back to self-organization, not just enforce a timebox.

A GOOD ANSWER COVERS: A strong answer outlines a multi-step, escalating approach. First, re-center the team by reminding them of the 'why' behind the 15-minute timebox and the event's goal. Second, introduce a specific facilitation technique during the meeting, like a 'parking lot' or 'offline' board, to capture topics that require deeper discussion. Third, explicitly schedule a follow-up meeting immediately after the Daily Scrum for only the necessary people to address the parked topics. Fourth, if the behavior persists, provide direct, one-on-one coaching to the individuals who consistently derail the conversation, perhaps in the Sprint Retrospective or privately.

COMMON WRONG ANSWERS: A red flag is an answer that is purely authoritarian, like 'I'd use a timer and cut people off when it goes off.' This shows a lack of coaching skills. Another weak answer is solving the problem for the team, which undermines their self-management. Simply telling the team 'we need to be faster' without providing tools or structure is also a poor response. Finally, citing the old 'three questions' (what I did yesterday, today, and blockers) as the definitive solution is a sign of outdated knowledge, as the 2020 Scrum Guide focuses on progress toward the Sprint Goal.

LIKELY FOLLOW-UPS: 'What if the team resists and says they find the problem-solving sessions valuable?' (Answer: Acknowledge the value but frame it as a separate, optional meeting to respect everyone's time). 'What if the person derailing the meeting is the Product Owner or a senior stakeholder?' (Answer: Coach them privately on the purpose of the event and their role, protecting the Developers' time).

ONE CONCRETE EXAMPLE: 'In a previous team, our Daily Scrum regularly hit 25-30 minutes. I brought it up in the Sprint Retrospective, and the team agreed it was an issue. In the next Daily Scrum, I brought a whiteboard and said, 'Let's try a parking lot. Any topic that needs more than a 60-second discussion, we'll write it here and tackle it right after with whoever needs to be there.' The first day, we parked three items. The Daily Scrum finished in 12 minutes. The follow-up meeting took 20 minutes but only involved three of the eight developers, saving the rest of the team significant time.'