Daily Scrum ticket updates: what primary purpose is missing?

WHAT THIS TESTS: This question tests whether you understand the empirical foundation of Scrum, specifically that the Daily Scrum exists for inspection and adaptation rather than status reporting. The interviewer wants to see if you recognize that the event is owned by the Developers and centers on the Sprint Goal, not on individual task updates.

A GOOD ANSWER COVERS: First, state clearly that the primary purpose is to inspect progress toward the Sprint Goal and adapt the upcoming plan, typically by updating the Sprint Backlog. Second, explain that the described format is a status-report anti-pattern where individuals report to the group rather than the team collaboratively managing its work. Third, emphasize that the Daily Scrum is for the Developers, not for the Scrum Master, Product Owner, or managers to gather updates. Fourth, note that effective Daily Scrums result in a shared plan for the next 24 hours that advances the Sprint Goal, which may include reassigning work, removing impediments, or adjusting priorities.

COMMON WRONG ANSWERS: Saying the problem is that the meeting takes too long or lacks an impediment question misses the structural issue. Suggesting the fix is to add the Scrum Master or Product Owner to receive updates inverts the event's purpose. Proposing stricter timekeeping or a different ticket tool does not address the missing focus on the Sprint Goal. Any answer that frames the Daily Scrum as accountability or reporting to leadership signals a fundamental misunderstanding.

LIKELY FOLLOW-UPS: The interviewer may ask how you would coach a team out of this pattern, what you would do if a manager insisted on attending for updates, or how the Sprint Goal changes the conversation. They might also ask how the 2020 Scrum Guide reframed the Daily Scrum away from the three questions and toward a single plan for the next day.

ONE CONCRETE EXAMPLE: Imagine a team with a Sprint Goal to reduce checkout latency. In the ticket-listing format, a developer says she worked on database indexing yesterday and will work on caching today. In a purpose-driven Daily Scrum, the team instead discusses whether the indexing moved the latency metric toward the goal, realizes the caching task is blocked by a missing API contract, and adapts by pairing that developer with another to mock the interface so both can proceed. The output is a revised plan for the next 24 hours, not a list of completed tickets.