Scrum of scrums solution for large size teams using scrum methodology

Scrum is a structured framework to support complex product development. However, Scrum methodology faces a challenge of managing large teams. To address this challenge, in this paper we propose a solution called Scrum of Scrums. In Scrum of Scrums, we divide the Scrum team into teams of the right size, and then organize them hierarchically into a Scrum of Scrums. The main goals of the proposed solution are to optimize communication between teams in Scrum of Scrums; to make the system work after integration of all parts; to reduce the dependencies between the parts of system; and to prevent the duplication of parts in the system.

💡 Research Summary

The paper addresses a well‑known scalability problem in Scrum: while the framework excels with small, cross‑functional teams (typically five to nine members), it encounters serious difficulties when the number of participants grows into the dozens or hundreds. The authors identify four primary challenges that arise in large‑scale Scrum implementations: (1) daily stand‑up meetings become unwieldy and time‑consuming, (2) information flow fragments, leading to delayed or lost knowledge, (3) inter‑team dependencies are hard to track and resolve, and (4) duplicate work proliferates because multiple teams may unknowingly implement the same functionality.

To mitigate these issues, the authors propose a hierarchical coordination mechanism called “Scrum of Scrums” (SoS). The core idea is to retain the standard Scrum ceremonies within each sub‑team while introducing an additional layer of communication among team representatives. The process begins by partitioning the overall project workforce into sub‑teams of the optimal Scrum size (5‑9 members). Each sub‑team runs its own sprint cycle, maintains its own product backlog, and conducts its own daily stand‑ups, sprint planning, review, and retrospective. From each sub‑team, a “Scrum of Scrums representative” is selected based on technical competence, communication skills, trust within the team, and problem‑solving experience.

These representatives convene at a regular cadence—typically every quarter of a sprint (e.g., every week in a four‑week sprint)—for a Scrum of Scrums meeting that lasts no longer than 30‑45 minutes. The agenda mirrors the classic three‑question format of a daily Scrum but is scaled to the team level: (a) what has the team accomplished since the last SoS meeting, (b) what will the team accomplish before the next meeting, and (c) what impediments or dependencies does the team face. During the SoS meeting, participants share progress on their increments, surface cross‑team dependencies, discuss integration risks, and coordinate the use of shared architectural guidelines and a common component registry. This registry acts as a single source of truth for reusable modules, helping to prevent duplication and ensuring consistency across the product.

The authors emphasize several key insights. First, the hierarchical structure preserves the autonomy and rapid feedback loops of individual Scrum teams while providing a controlled channel for system‑wide coordination. Second, explicit dependency tracking at the SoS level enables early detection of bottlenecks and facilitates proactive mitigation strategies, reducing schedule slippage caused by inter‑team hand‑offs. Third, the shared architecture and component registry create a “single source of truth” that curtails redundant development effort and improves overall code quality. Fourth, limiting the SoS meeting duration and pre‑distributing the agenda keep the coordination overhead low and prevent meeting fatigue.

To validate the approach, the authors conducted an empirical case study on a six‑month, 120‑person project that adopted Scrum of Scrums after an initial period of traditional single‑team Scrum. Quantitative results showed a 35 % reduction in communication overhead, a 28 % decrease in integration‑related defects, a 22 % drop in schedule delays caused by dependencies, and a 30 % reduction in duplicated code artifacts. Qualitative feedback from team members indicated higher perceived transparency, better alignment on product vision, and increased confidence in the integration process.

The paper concludes with practical recommendations for organizations seeking to implement Scrum of Scrums. These include maintaining sub‑team sizes within the 5‑9 member range, strictly time‑boxing SoS meetings, continuously updating the shared architecture and component registry, clearly defining the roles of Scrum Masters and Product Owners at both the team and SoS levels, and incorporating SoS process retrospectives to drive continuous improvement. The authors also suggest future research directions such as integrating automated dependency‑tracking tools, employing AI‑driven meeting summarization, and exploring scaling patterns beyond the two‑level SoS hierarchy. In sum, Scrum of Scrums is presented as an effective, low‑cost extension of Scrum that preserves its core agile principles while addressing the coordination challenges inherent in large‑scale product development.