Remove Definition of Outcome and focus more on Sprint Goal as an outcome driven goal #29
Replies: 9 comments 25 replies
-
|
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, |
Beta Was this translation helpful? Give feedback.
-
|
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 :)? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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
B. In the "Scrum Events" Section (under The Sprint)
(Proposed New Text with Change)
C. In the "Scrum Events" Section (under The Sprint Review)
(Proposed New Text with Addition)
Part 2: Proposed Explanatory Text for the Scrum Guide Expansion Pack (SGEP)
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
As promised, my article on validation is at #118 . Feedback is very welcome. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
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
Beta Was this translation helpful? Give feedback.
All reactions