Remove Definition of Outcome and focus more on Sprint Goal as an outcome driven goal

[Ziryan-salayi]

I agree with the statement made by @SVPavlov in his LinkedIn post: While the focus on outcomes is right, formalising it as a new "Definition" is a misstep. It risks becoming a bureaucratic checklist, encouraging teams to sub-optimize by validating individual items rather than their overall strategy. Validation is a continuous discovery activity, not a new definition.

Additionally, I think it even creates a gap between teams focusing on DoD (Technical) and other teams on DoOutcome.
Also, the PO is accountable for the ROI of the product, the goals should be more focused on Outcomes and therefore also shift towards long-term metrics to measure the assumed outcome rather than only on Sprint results

[KysukeX]

I'm also not a big fan of 'DoOD.' It would be better to call it 'Outcomes Validation' or 'Product Success.' This commitment should validate or invalidate the direction we are taking with the product. If individual increments are small hypotheses, the overall product represents a larger one, generating more significant and visible outcomes.

Having a rigid definition makes things too restrictive. Product success and desired outcomes vary considerably from one product to another, and a fixed definition implicitly suggests a standard recipe for every product/outcome.

These observation processes correlate with EBM (Evidence-Based Management), so in my opinion, it's not necessary to coin another definition. However, it's certainly beneficial to have a commitment ensuring that practitioners inspect whether the product is generating positive and valuable outcomes or not.

Best Regards,
Lamine Haouam

[SVPavlov]

Nice going all. Obviously I very much agree.

Thank you for contributing to the discussion, @SVPavlov. I have been reflecting on the concept of value validation. Feedback is a gift.

I can imagine how value validation could be discussed in Refinement and the Sprint Review when the Scrum Teams interacts with Stakeholders. My hope is that members of the Scrum Team need to "get out of the building" throughout the Sprint to observe usage and experience by more external stakeholders. Maybe the document needs to be more explicit about that. Thoughts?

I agree. Getting out of the building would help a lot. I also feel that "refinement" or "backlog grooming" as we once called it imply an internal focus. "Discovery & validation" makes it more explicit that it is an activity that requires teams to collect feedback in order to figure out what to do next. Refinement can be mentioned in the description if needed. More importantly the DooD (death in Dutch btw ☹️) validation of a single PBI is sometimes a bit pointless and leads to suboptimalization. Validation is an activity that can be done through experimentation and releasing stuff to the market but validation is also done on a business model and strategy level. Especially in those early stages before products "cross the chasm". Startups are essentially businesses without a functional business model. Their goal is to find a working one. Not to validate single PBI's.

In short.

The "definition of outcome done" is in my opinion a big mistake with the right intentions.

[rjocham]

@SVPavlov there is a difference between Outcome Done which is for the overall product or larger features (composed out of several PBIs). Think customer happiness, market share, synergies, ... . On PBI level there are Outcome Criteria. Could it be that you are confusing the two ideas?

[SVPavlov]

@rjocham No I am aware of these differences in the SGEP. I think in reality the difference isn't that distinct sometimes.

More importantly.
When would teams validate either of these two ideas and why?

[rjocham]

Outcome Criteria are used for individual PBI if applicable.
Outcome Done is as mentioned before.

[Ziryan-salayi]

can you imagine we then have DoD teams and DoOD teams?

I think I see where you're going @Ziryan-salayi . I have regrettably already observed "Definition of Sprint Done" and "Definition of Release Ready" in multi-team setups, but not yet in separate teams (although I can envision this scenario). Perhaps the document needs to be more explicit about interlacing value validation. Thoughts?

yes, although not the intention, such teams may be created.
I think it would indeed be more valuable to highlight how metrics, for example, can support in setting powerful outcome-driven Sprint Goals (and product goals)

[ViralGoodAgile]

Hi @Ziryan-salayi - Thank you for bringing this to our attention. You raise some interesting food for thought. For context: part of the intent behind the Definition of Output Done is that it helps to improve trust from Stakeholders and gives them a sense that they know what they're looking at when the Increment is reviewed. Part of the intent behind the Definition of Outcome Done, is to get agreement on what evidence or observations would indicate product outcomes. We're trying to reduce the chances of people declaring victory after releasing, oblivious to the failure demand creation (negative value). Outcome Criteria offer flexibility for declaring evidence or observation expectations for outcomes for individual items. In essence, we're treating each Product Backlog Item as a hypothesis for value, but we're open to the idea of probes, e.g., based on hunches.

Is your objection mainly to the naming of the Definition of Outcome Done or the concept, or both :)?

[ViralGoodAgile]

Hi @KysukeX - we agree that the direction of travel could end up being wrong. We suggest, for example, that the Product Goal could be adapted, and that the vision could be completely wrong. The Definition of Outcome Done is more about an attempt to predetermine what telemetry, metrics, or observations Scrum users would review before "declaring victory". We have suggestions also about probes based on hunches, not necessarily hypotheses. We might not know what would happen. Definition of Outcome Done is not meant to be comprehensively exhaustive, and maybe the document should say that. Thoughts?

[KysukeX]

Hi @KysukeX - we agree that the direction of travel could end up being wrong. We suggest, for example, that the Product Goal could be adapted, and that the vision could be completely wrong. The Definition of Outcome Done is more about an attempt to predetermine what telemetry, metrics, or observations Scrum users would review before "declaring victory". We have suggestions also about probes based on hunches, not necessarily hypotheses. We might not know what would happen. Definition of Outcome Done is not meant to be comprehensively exhaustive, and maybe the document should say that. Thoughts?

The main issue I have with DoOD is the naming, it's just too confusing. You can't differentiate both based on acronyms (Both are DoOD dude ...). Secondly, DoD is already well established, and adding a new "DoD" will make people use the same logic (checklisting) and try to standardize outcomes, which is more complex to do in comparison with output.

Renaming it with something like 'Outcomes/Product Validation/Success' make a real difference with the original DoD, there will be a clearer difference between these two commitments.
Once again I'm not against the idea to forecast and mesure outcomes, but a proper naming will drastically reduce confusion and missusage.

[Ziryan-salayi]

Part of the intent behind the Definition of Outcome Done, is to get agreement on what evidence or observations would indicate product outcomes

I do agree with the intent to highlight more outcome-driven goals. Perhaps not use a DoOD, but rather highlight characteristics of a Goal as part of Refinement or sprint planning? In our courses, we discuss that a goal without a way to validate the achievement is just as worthwhile as horoscopes in yesterday's paper. Once delivered, you can always convince yourself that it was a good goal :)

[SVPavlov]

Just to be clear. I dont think that the sprint goal is the only solution. The problem. That the DooD tried to solve was the lack of “Discovery and Validation” done in Refinement.

I am still on the fence for relabelling refinement to “Discovery & Validation”. If needed Refinement can be mentioned in the text.

[rjocham]

How would you like to call them? I realized that I mostly talk about 'Output Done' and 'Outcome Done'. Maybe Definition of ... is a legacy construct that we don't need nay more.

Personally I am big fan of using powerful outcome driven Sprint Goal. Would it be enough doesn't it help to have product related outcome criteria defined upfront.

[SVPavlov]

I've found that using outcome-based sprint goals can be very effective. One key challenge, however, is that validating our assumptions can sometimes take longer than expected.

For instance, determining whether we’ve achieved Product Market Fit (PMF) often requires us to analyze various metrics that can guide our understanding. We might start by examining metrics like Total Addressable Market (TAM), especially within the context of identifying early adopters in our target market. As we look to “cross the chasm,” it may be beneficial to consider TAM in adjacent markets as well.

Additionally, while some metrics may be tied directly to product releases, others may provide valuable insights about the market, even if they aren’t directly related to the product itself.

These insights may not always fit neatly into a traditional framework, but they can certainly play a vital role in our refinement processes or what we might soon refer to as “discovery and validation.” Embracing this broader perspective can ultimately enhance our approach and lead to more successful outcomes.

[Ziryan-salayi]

I would actually leave the criteria out and provide more emphasis on why outcome-driven Sprint Goal is important and how powerful outcome-drive Sprint Goals can get you a step closer to deliver value in the discovery and validation process?

[SVPavlov]

@rjocham @ViralGoodAgile

Below is a first draft of how I would amend the SG based on my ideas and this conversation.

I iterated with Gemini a couple of times.

Part 1: Proposed Rewrites for the 2020 Scrum Guide
This revised proposal integrates the Product Goal commitment directly with the Product Backlog description and formally replaces "Refinement" with "Discovery & Validation," using terminology consistent with the 2020 Scrum Guide.
A. In the "Scrum Artifacts" Section: The Product Backlog
This proposal restructures the entire Product Backlog section.
(Proposed New Structure and Text for the Product Backlog Section)

Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
Discovery & Validation
Discovery & Validation is the ongoing activity of breaking down and further defining Product Backlog items into smaller, more precise items. It is how the Scrum Team adds details, order, and size to the Product Backlog.
This activity is a collaborative effort involving the entire Scrum Team. The Product Owner may influence the Developers by helping them understand and select trade-offs. However, the Developers who will be doing the work are responsible for the sizing.
Through this ongoing product backlog refinement, the Product Owner ensures the Product Backlog is transparent and ordered to maximize value.

B. In the "Scrum Events" Section (under The Sprint)
(Current Text)

...Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

(Proposed New Text with Change)

...The Sprint Backlog may be adapted as more is learned through ongoing Discovery & Validation.

C. In the "Scrum Events" Section (under The Sprint Review)
(Current Text)

During the Sprint Review, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

(Proposed New Text with Addition)

During the Sprint Review, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Progress toward the Product Goal is discussed. This is a formal opportunity for Validation with stakeholders.
Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

Part 2: Proposed Explanatory Text for the Scrum Guide Expansion Pack (SGEP)
This text provides the rationale for the proposed changes to the core guide.

Why Refinement is Now Discovery & Validation
The Scrum Guide has been updated to rename the ongoing activity previously known as "refinement" to Discovery & Validation. This is an explicit change to correct a common misunderstanding where refinement was seen as a purely internal, mechanical task of preparing a backlog.
The new name clarifies the true dual purpose of this crucial activity:

• Discovery is the continuous process of exploring the problem domain and understanding stakeholder needs to determine what is valuable. It compels the Scrum Team to look outward.
• Validation is the empirical process of testing the assumptions underlying the product strategy and business model. It connects the team's work back to the "why."
  Connecting to the Product Goal
  We have also moved the Product Goal commitment to be featured alongside the description of Discovery & Validation. This is intentional. The Product Goal provides the essential context for this activity. The team discovers what is valuable and validates its assumptions in service of achieving the Product Goal. This structural change makes it clear that Discovery & Validation is not a context-free activity but is the primary mechanism through which the Scrum Team navigates its path toward its long-term objective.
  This approach solves the problem that the concept of a "Definition of Outcome Done" attempted to address. It embeds the focus on outcomes and value directly into a core activity, without adding a new, prescriptive artifact. Adding a formal "Definition of Outcome Done" risks creating bureaucratic checklists and encouraging teams to sub-optimize by validating individual items. True outcomes are validated against the overall strategy and the Product Goal. By renaming the activity and placing it alongside the Product Goal, the guide now emphasizes that discovering value and validating strategy are not separate from the work—they are the work.

[SVPavlov]

Frankly speaking I think this draft needs work as well. I would also link Product goal to strategy

[rjocham]

@SVPavlov I am unclear about what you mean with validation. Is it we reached our goal or is it we found out it is the right feature to build. It seems validation happens in the Review, what about the Review?

[SVPavlov]

@rjocham Your question points to the problem with trying to over-define these things in a guide.
Validation isn't a choice between "did we reach our goal" or "did we find the right feature to build." It's both, and it's continuous. The framework should enable this, not create false dichotomies.
Validation happens at different levels:

• During a Sprint: We are constantly validating ideas and approaches to solve problems. This is formative and part of the ongoing Discovery & Validation activity.
• At the Sprint Review: This is the key formal event where we validate the tangible Increment with stakeholders. It’s where we inspect the result of our work and get data to adapt. It is an important validation point, but not the only one.
  Frankly, we shouldn't get bogged down in defining "validation" perfectly. The only thing that matters is that the Scrum Team has a framework that helps them learn. The goal isn't to have a perfect definition; it's to build a valuable product. Validation is the work, not a new definition. The Sprint Review is simply the most important formal opportunity to do inspect and figuring out what to do next by adapting the product backlog with people outside the team.

These are just two examples but the activity also spans the intermediate goal(s) ie the current product goal and possible future ones. The traction the product goal has so far is incredibly low. In my observations its often two abstract of a thing and teams are not quite sure where it fits in an event or what one should look like.

[ViralGoodAgile]

Hi folks, it helps me to communicate the intent and clarify thoughts using articles. Often, before a debate, it's helpful to clarify the meaning of words. My attempt: I've written a long-form article that Ralph is reviewing on the topic of outcome measurement. I want to create a new discussion on GitHub with that article before sharing it on Substack, Medium, or LinkedIn. And I'm happy to shape it based on your feedback. I'll post the long-form article as a discussion on Monday, 16th June 2025.

I will write a separate long-form article on value realization. That will take me a few days, possibly until June 20th.

Contributors, do you agree that this could be a healthy approach to facilitate productive and constructive debate?

[KysukeX]

What would be helpful would be to work iteratively, let's start by first changing the naming of Definition of Outcome Done and observe the impact on the document, then we can debate where we should focus our attention.

[rjocham]

We would like to have a chat with you. We are thinking about having a Zoom call. Nothing beats having a live in person conversation.
Let us know if this would be ok for you. Then we can find a suitable time slot.

[SVPavlov]

We would like to have a chat with you. We are thinking about having a Zoom call. Nothing beats having a live in person conversation.

Let us know if this would be ok for you. Then we can find a suitable time slot.

I am assuming this includes or is directed at me?

[rjocham]

Here is a Doodle poll. https://doodle.com/group-poll/participate/b6K1zznd for all of you.
Would be great if one of those time slots works for as many people as possible.
Anyone can sign up ;)

[SVPavlov]

Sorry none of the time work for me. After work it's family time for me.

[ViralGoodAgile]

Hi folks.

For now, I started a discussion on optionality in the Scrum Guide Expansion Pack (SGEP) in #104 and a discussion on Having Quality Standards for Outcome Measurement–Outcome Done and Outcome Criteria in #105. I request that contributors help me improve the text in those discussions for later social media posting, and I'm happy to acknowledge those who assist.

Key points:

• Most of the SGEP contains optional content. The SGEP states that the 2020 Scrum Guide describes Scrum. In the SGEP, both the Definition of Outcome Done and the Outcome Criteria are optional. Acceptance Criteria are also optional, for example.
• I agree (with what I think is being said more or less in this discussion here) that goals should have measurements (quantitative and qualitative). I take that as a given.
• I disagree that definitions for words do not matter. Part of the ethos of the SGEP is clearer definitions.
• The SGEP proposes quality outcome standards (not happy wth that word 'standards', will try to think of a better word).
• @rjocham and I are open to a discussion on renaming 'Definition of Outcome Done,' and we're open to suggestions. When writing about it, I already shorten it to Outcome Done, for example.
• Is anything ever really done (output or outcome) really? Are outputs more like unfinished art that one can continually revisit? I like Mike Burrows's expression that 'done' means needs are met (or words to that effect).
• There are mixed topics in this discussion; each of them, in my opinion, is a significant topic. This coming week, with a view to a later long-form article on social media, I will write separate discussions on refinement, discovery, and value validation. I request that contributors help me improve the text in those discussions for later social media posting, and I'm happy to acknowledge those who assist.
• Scrum Guide updates are off the table in this forum, as SGEP has no control over that.
• Like many others, I'm sure, I cannot take time out of my consulting day for calls, and I don't have structured lunch hours. I can join early mornings or evenings, European time. I respect that others also have limits. I propose that if we cannot agree on a time for the calls, we will work with whoever can join, we'd record and publish the meeting notes (ideally an AI summary to reduce effort), and discuss here also. Please let me know your alternative suggestions. Either way, posting call summaries would be good for transparency.

[rjocham]

@ViralGoodAgile is going to write an article on social looking for suggestions.

[ViralGoodAgile]

As promised, my article on validation is at #118 . Feedback is very welcome.

[ViralGoodAgile]

Thanks, folks. We have been convinced to rename 'Definition of Outcome Done'. If you have suggestions, could you contribute some ideas? Bear in mind the intent at #105. Thank you.

[IwoHryniewicz]

I believe part of the confusion comes from using very similar names (Definition of Output Done and DoOD) for vastly different things. I appreciate the introduction of Product as a new artifact, but I believe what we're looking for are measurable success criteria for the whole product - not sth analogous to the traditional DoD - mostly, but not only, focused on the quality criteria. I also believe that "outcome" is too narrow, since what we aim at here are both outcomes and impacts - different things according to value chain. Perhaps Key Product Metrics would be a better term?