Scrum in Context: Stakeholders, Teams and Improvement
Domain focus
This domain tests Scrum beyond the team room: stakeholder collaboration, organizational support, team development, scaling claims, and continuous improvement. Questions often probe who engages stakeholders, how impediments are removed, and how metrics support learning rather than control.
Stakeholders and the Product Owner
Stakeholders include customers, users, sponsors, operations, compliance, and suppliers. The Product Owner engages them to shape and order the Product Backlog and to communicate the Product Goal; the Sprint Review is the main recurring inspection point, not a one-off sign-off. Contracts and governance can either support or undermine empiricism. Fixed scope, fixed date, and fixed price together remove the ability to adapt; outcome-based contracts and collaborative supplier relationships preserve it. The Scrum Master helps the organization understand Scrum and remove impediments, but does not own product decisions.
Teams, environment, and scaling
Scrum Teams are self-managing, cross-functional, and ten or fewer people. Distributed teams need deliberate communication and working agreements. Management's role is to create an environment of psychological safety, provide support, and remove blockers, not to direct daily work. Scaling frameworks such as LeSS, Nexus, Scrum@Scale, and SAFe address multi-team coordination; they are outside the Scrum Guide, which does not prescribe a scaling method. "Bigger Scrum" is not scaling: adding teams without integration and a shared Definition of Done produces local optimization.
Improvement and useful measures
The Retrospective is the team's improvement event, but improvement must be followed by experiments and change. The Definition of Done is a quality guardrail; weakening it to show progress is a false gain. Useful measures include cycle time, escaped defects, stakeholder satisfaction, and progress toward the Product Goal. Evidence-Based Management suggests four value areas: current value, unrealized value, ability to innovate, and time to market. Avoid individual velocity rankings, story-point targets, and activity metrics that reward busyness over outcomes.
Worked example
A team's velocity rises for three Sprints, but customer complaints about defects also rise. The Retrospective examines the Definition of Done and finds that regression testing is manual and skipped. The team adds automated regression checks to the Definition of Done, tracks escaped defects, and reviews the trend with stakeholders at the Sprint Review. The reasoning: velocity is not a value measure by itself; transparency about quality lets the team inspect and adapt. The improvement is an experiment with a measurable signal, not a slogan.
Traps that cost marks
Do not limit stakeholder involvement to the Sprint Review. Do not assume a scaling framework is required by Scrum or that more teams mean more value. Do not use velocity to rank individuals or teams. Do not accept a Retrospective that produces no owned action. Do not weaken the Definition of Done to protect a metric. Do not describe the Scrum Master as the owner of all impediments; the team must surface them.