The home-robot company is forming its second Scrum Team as the app, firmware, and cloud work grows. A manager proposes splitting the single existing 9-person Scrum Team into a 'firmware sub-team' and an 'app sub-team' that each report separately to the Scrum Master, while keeping one Scrum Team name for reporting purposes. Does this satisfy the Scrum Guide's definition of the Scrum Team?
Select an answer to reveal the explanation.
Short Explanation
Calling two groups by one team name doesn't make them one team — it just hides the seams. The Guide's Scrum Team is a single, cohesive unit with no internal sub-teams reporting anywhere, including to the Scrum Master. If the work has genuinely outgrown one team, the honest move is forming a second real Scrum Team, not drawing an invisible line through the existing one.
Full Explanation
The 2020 Scrum Guide defines the Scrum Team as a small, cohesive unit of professionals with no sub-teams or hierarchies among them. Splitting one team into a 'firmware sub-team' and an 'app sub-team,' even under a shared name, recreates internal structure the Guide excludes by definition — it does not matter that a single label is preserved for reporting. Reporting both halves to the Scrum Master is also a mismatch, since the Scrum Master is not a manager the sub-teams report to; that framing misassigns the accountability entirely. Staying inside the recommended headcount doesn't rescue the arrangement either — size is a separate guideline from structure, and a team can be an acceptable size while still being organized as a hierarchy internally. The framework's actual answer to real growth is to split into two genuine Scrum Teams, each complete with its own Developers and Scrum Master accountability, coordinating through a shared Product Backlog rather than through an internal chain of command. A concrete check: ask whether either sub-team can plan and deliver a Sprint on its own — if not, it isn't really a separate team, and it shouldn't be a hidden hierarchy either.