In June 2025, Ralph Jocham, John Coleman, and Jeff Sutherland published the Scrum Guide Expansion Pack — a companion document to the 2020 Scrum Guide designed to address the gaps that practitioners had been navigating quietly for years. It does not replace Scrum. It extends it. And in doing so, it asks a question the original guide never quite got around to asking: did value actually land?
The mechanism for that question is a new concept called the Definition of Outcome Done — a companion to the existing Definition of Output Done. Output Done asks whether the work was completed. Outcome Done asks whether completion produced anything meaningful. The distinction is real, and it matters. A feature can ship cleanly and still fail. A program can run on schedule and still not move anything worth moving.
This is a genuine step forward for Scrum practitioners — and for anyone using agile frameworks to manage programs that touch people’s lives directly. But the Expansion Pack’s new question surfaces a harder one that it doesn’t answer: whose outcome counts? And more specifically: who is in the room when that gets decided?
What the Expansion Pack Gets Right
The 2020 Scrum Guide was built for simplicity. Its minimalism was intentional — Scrum’s founders wanted a framework light enough to travel across industries, contexts, and team sizes without becoming prescriptive. That worked. Scrum left software development and spread into marketing, education, healthcare operations, HR, and benefits administration. The framework adapted because it was designed to adapt.
But simplicity has a cost. The 2020 Guide describes value delivery without defining what value means or how to verify it. Sprint Reviews inspect the Increment. Retrospectives surface process failures. Neither event has a built-in mechanism for asking whether the thing delivered actually changed anything for the people it was supposed to serve.
The Expansion Pack addresses this directly. By formalizing the Definition of Outcome Done alongside the Definition of Output Done, it creates a structural checkpoint for value realization — not just value delivery. Did the outcome we intended actually occur? Is there observable evidence that something moved? The framework now asks teams to hold themselves accountable not only for completing work, but for what that work produced in the world.
For Product Owners in particular, this is a significant expansion of accountability. The Product Owner has always been responsible for maximizing value. The Expansion Pack sharpens that responsibility into something measurable: value must be defined in terms of outcomes, and outcomes must be verified against observable evidence. That is a harder standard to meet — and a better one.
The Stakeholder Model Has a Gap
Scrum’s stakeholder model is built around presence. Stakeholders are the people who show up — sponsors, business owners, end users who participate in research, team members, organizational leadership. The Sprint Review is designed to surface their feedback. Backlog refinement incorporates their priorities. The Product Owner synthesizes their needs into an ordered backlog.
This model works well when the people affected by a product are also the people represented in the process. But there is a class of program — common in wellness, benefits, HR, and health data management — where that assumption breaks down quietly and completely.
In these programs, the people whose data is being collected, measured, analyzed, and acted upon are rarely in the sprint review. They did not commission the product. They did not write the acceptance criteria. They may not know the program exists in its current form, or what data it holds, or how that data is being used to make decisions about them. They are, in the governance sense of the term, data subjects — the individuals to whom the data belongs at its origin, whose behaviors and health states and participation patterns are the raw material of the program’s entire value proposition.
Data subjects are stakeholders in every meaningful sense. The program exists because of them. Its outcomes land on them. Its errors affect them. And yet they are structurally invisible in agile processes built around the stakeholders who show up.
And they are not a monolithic group. Data subjects include people who never participated at all, people who participated partially, people exposed to program decisions without knowing it, and people affected by error, burden, or coercion built into the program’s design. What they share is not a behavior — it is a structural position. The program acts on them. They do not act on the program.
This is not a failure of intent. Most product teams operating in these spaces care about the people their programs serve. The invisibility is structural. Sprint ceremonies are designed for the people in the room. Data subjects, by definition, are not in the room — and no element of the standard Scrum framework, including the Expansion Pack’s new Outcome Done definition, creates a mechanism for putting them there.
The result is a stakeholder problem embedded in the definition of outcome itself. If the people whose outcomes matter most are absent from the process of defining what “done” looks like, then the Definition of Outcome Done is measuring outcomes for the organization — not for the people the program is supposed to serve. Those are not always the same thing. In programs that carry real power asymmetry — employer-sponsored wellness, managed benefits, population health — they are frequently quite different.
ETHICMAP Puts Data Subjects in the Room
ETHICMAP is a Small Data Ethics framework built for repeatable program operations — programs that run in cycles, collect data from real people, and produce decisions that affect those people’s lives. It was designed specifically for the operational context where governance failures are most likely to be invisible: not at launch, but mid-cycle, after the program is running and before anything has visibly gone wrong.
The framework is structured as an implementation cycle with eight dimensions. Four of them map directly onto the gap the Expansion Pack’s Outcome Done definition leaves open.
Harmony asks: for whom does this work — who benefits, who is burdened, who is exposed? This is the dimension that makes data subjects visible as a distinct stakeholder class. It forces the question the sprint review does not: are the people whose data powers this program experiencing it as beneficial, neutral, or harmful? Are the burdens of participation distributed equitably? Are the people most exposed to program decisions the same people who had the least input into program design? Harmony does not assume that organizational outcomes and participant outcomes are aligned. It requires you to check.
Incentive asks: why would someone participate — and does participation remain feasible without becoming coercive? In employer-sponsored programs, this question carries significant weight. Participation is rarely purely voluntary. Financial incentives, social pressure, and employment context all shape the conditions under which data subjects engage with a program. The Expansion Pack’s Outcome Done asks whether value was realized. Incentive asks whether the pathway to that value was one participants could meaningfully choose — or whether “participation” was the only option that didn’t cost them something.
Measurement asks: what moved — and what are the uncertainty and error rates, not just the point estimates? This dimension directly challenges a common failure mode in outcome measurement: reporting a result as though it is clean when the underlying data is noisy, incomplete, or systematically biased toward people who engaged most visibly. Data subjects who did not participate, who participated partially, or whose data was excluded from analysis are still stakeholders in the program’s outcomes. Measurement discipline requires accounting for them — not just reporting on the population that produced clean data.
Environment asks: where are we operating — what are the constraints, norms, and power dynamics? In any program that operates within an employment relationship, power dynamics are not background context. They are active variables. Data subjects in employer-sponsored programs are not consumers choosing between competing products. They are employees navigating an institution that holds significant power over their livelihoods. Environment surfaces that asymmetry as a design constraint, not an afterthought.
Together, these four dimensions operationalize the question the Expansion Pack raises but cannot answer on its own. Outcome Done asks whether value was realized. ETHICMAP asks for whom, under what conditions, measured how, and in what power context. That is not a philosophical addition to the framework. It is the methodology that makes Outcome Done answerable in programs where data subjects are the source of value and the target of outcomes simultaneously.
A Complete Definition of Outcome Done
The 2025 Expansion Pack is a meaningful document. Its authors understood that Scrum had outgrown its original context and needed guidance that traveled with it into harder territory — AI integration, complex stakeholder ecosystems, outcome accountability. The Definition of Outcome Done is the right question at the right time.
But a definition of outcome is only as complete as the population it accounts for. In programs that collect and act on data from real people — wellness programs, benefits administration, population health initiatives, HR analytics — the people whose data drives the program are not incidental. They are the program. Their outcomes are the outcomes. And if they are absent from the process of defining what “done” looks like, the framework is measuring something narrower than it believes.
ETHICMAP does not replace Scrum. It does not replace the Expansion Pack. It is the governance layer that makes outcome measurement honest in contexts where data subjects exist and matter — which is most of the contexts where agile frameworks are now operating.
A Product Owner who wants to meet the standard the Expansion Pack sets needs a methodology for asking: did value land for the people who couldn’t be in the sprint review? ETHICMAP is that methodology. It is built for exactly this: repeatable programs, real people, invisible risk, and the governance discipline to see what the process alone cannot show you.