What is a Scrum of Scrums, and what do you share there?

WHAT THIS TESTS: This question tests your understanding of how to scale Agile principles. Interviewers want to see if you can think beyond your own team's sprint backlog and engage in program-level coordination. They're evaluating your ability to identify, communicate, and resolve cross-team technical dependencies and risks. It's a test of proactive problem-solving, not just reporting status.

A GOOD ANSWER COVERS: A strong answer has four parts. First, define the Scrum of Scrums (SoS) as a mechanism for multiple teams working on a single product to coordinate, not just a status update. It's a problem-solving and dependency-management meeting. Second, describe what you share: focus on technical information relevant to other teams. This includes progress on integration points, newly discovered dependencies, or potential blockers like an upcoming breaking change in a shared API. Third, describe what you receive: you're listening for blockers from other teams that might impact you, changes in their timelines for shared components, or solutions to problems you might also face. Fourth, state the frequency and participants: typically 2-3 times a week, attended by a representative from each team (often the Scrum Master or a designated technical lead).

COMMON WRONG ANSWERS: A major red flag is describing the SoS as just a bigger daily standup where each team lists what they did, what they will do, and their blockers. This is too tactical and misses the strategic coordination aspect. Another mistake is focusing only on your team's accomplishments without connecting them to the larger product goals or other teams' work. A senior engineer should be focused on integration and shared risk, not just their own story points. Finally, saying you've never been in one is okay, but you must then describe how you would expect it to work based on first principles of managing dependencies.

LIKELY FOLLOW-UPS: "Describe a time a Scrum of Scrums helped resolve a major technical blocker." "What happens when an issue raised in the SoS can't be solved by the people in the room?" "How does the information from a SoS flow back to your team?"

ONE CONCRETE EXAMPLE: "In a recent project, my team was building a new checkout service that depended on a pricing service from another team. In the Scrum of Scrums, I reported that we were on track to deliver our client-side integration by Wednesday. The pricing team's rep then flagged that they had discovered a performance issue under load, and their fix would delay their deployment by two days. Because we learned this in the SoS, we could immediately pivot to work on another feature for two days instead of being blocked. We also used the meeting to agree on a new integration testing time, preventing a multi-day slip for the entire feature launch."