Complex Projects
Domain 4, Complex Projects, tests how Scrum is applied when one product involves multiple teams, dependencies, distribution, contracts, or governance. The exam favors empirical coordination over adding predictive control.
Core rules
- Complexity means many interacting parts and emergent outcomes. A complicated problem can be analyzed in advance; a complex product needs short feedback loops and adaptation.
- Scaling Scrum starts with one product vision, one ordered Product Backlog, and aligned product ownership. Multiple teams should not create competing backlogs for one product.
- Common scaling approaches include Scrum of Scrums, Nexus, LeSS, and SAFe. They differ in detail, but all rely on transparency, integration, and regular adaptation. A Scrum of Scrums coordinates and removes impediments; it is not a status committee that overrides the Product Owner.
- Dependencies should be made visible, minimized, and resolved through cross-team refinement, shared Sprint Goals, a shared Definition of Done, and integrated Increments. Reporting dependencies without changing work is not enough.
- Distributed teams need deliberate working agreements, overlapping hours, clear communication channels, and accessible information. Co-location helps but is not a Scrum rule.
- Fixed-price, fixed-scope contracts conflict with empirical delivery. Better contracts fund capacity or units, allow scope flexibility, and require incremental delivery and collaboration. Architecture and documentation should be sufficient and intentional, not comprehensive upfront.
Worked example
Two teams build one product; each plans separately, and integration fails late. A weak answer adds a weekly status meeting. A better answer puts the shared dependency on both backlogs, aligns Sprint Goals, includes integration in each Definition of Done, and holds joint refinement. Reasoning: coordination must change the work and make integration transparent; a meeting that only reports progress does not reduce the dependency.
Traps
Do not scale by adding layers and committees. Do not assign one Product Owner per team for a single product. Do not treat Scrum of Scrums as a reporting meeting. Do not assume a fixed-scope contract is Agile because the team uses Sprints. Do not claim distributed teams cannot use Scrum. Do not over-plan architecture upfront.