What is a Scrum of Scrums purpose and what technical info is shared?

WHAT THIS TESTS: This question checks whether you understand Scrum beyond the single-team level. Interviewers want to see that you know how scaled coordination works without reverting to waterfall status meetings. They are listening for systems thinking: how technical decisions in one team create friction or blockers for another, and how engineers proactively surface those issues rather than waiting for management to discover them.

A GOOD ANSWER COVERS four things in order. First, define the Scrum of Scrums as a coordination and integration mechanism for multiple teams working on the same product or platform, not as a governance layer. Second, identify who attends: typically technical ambassadors or rotating engineers who can speak to dependencies and blockers, not just Scrum Masters or managers. Third, list the technical information exchanged. This includes cross-team dependencies, upcoming API or schema changes, environment or pipeline failures affecting multiple teams, integration risks, and architectural decisions that need alignment. Fourth, state the purpose clearly. The goal is to resolve impediments and optimize flow across teams, not to report status upward or compare velocity metrics.

COMMON WRONG ANSWERS include describing the meeting as a daily standup for team leads where each person recites what their team completed yesterday. Another red flag is framing it as a management reporting ritual used to pressure slower teams. A third mistake is listing only generic project management updates like burndown charts or sprint goals without mentioning technical integration concerns.

LIKELY FOLLOW-UPS include asking how you would handle a dependency that another team cannot commit to, or how you would escalate a cross-team architectural dispute. The interviewer might also ask how often the meeting should occur, probing whether you understand that frequency depends on integration cadence rather than a fixed calendar rule.

ONE CONCRETE EXAMPLE: Suppose your team is changing a payment service API response format. In the Scrum of Scrums, you would flag the breaking change, share the target deployment date, identify the two consumer teams affected, and propose a temporary backward-compatibility window. You would then receive feedback on their release schedules and agree on a joint integration test slot. This turns a potential production incident into a managed, collaborative rollout.