"potentially releasable" vs. "Commitment: Definition of Done" - Scrum Guide 2020
Hi Folks,
checking the new Scrum Guide 2020 I wondered why they changed the "potentially releasable" increment to be more focused on the commitment for the DoD. Here some examples.
Definition of Done
Scrum Guide 2017
The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
Scrum Guide 2020
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
Development Team
Scrum Guide 2017
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
Scrum Guide 2020
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
Increment
Scrum Guide 2017
The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Scrum Guide 2020
In order to provide value, the Increment must be usable.[...]
Work cannot be considered part of an Increment unless it meets the Definition of Done.
For me "usable" does sound much weaker than "potentially releasable". It feels like a mere "It does not break immediately and gets the job done."
Merriam Webster
Definition of usable
1: capable of being used
2: convenient and practicable for use
The Scrum Guide 2020 would allow for a low level set of DoD and than "fixing it in post". In my opinion this opens the gates for having Hardening or Release Sprints.
I welcome to bring the DoD more in the focus to inspect and adapt them if an Increment does not meet the expectations. But somehow it lacks a lean approach.
What do you think?
How do you implement this into your daily Scrum work?
Did you change your DoD to include more strict quality rules like test code coverage, know bugs and performance?
It's the same Scrum as before. If "usable" is seen to imply a weaker standard, ask why. What's causing lowered expectations about the quality of work, and might lead to a slippery slope of technical debt and so-called "hardening sprints"?
Overall, I don't see any substantial differences. I'd point out a few things that are missing:
- The Definition of Done defines "the quality measures required for the product". All products must be at least usable. Other products may have more stringent quality measures required in order for them to be used. If it can't be used, it's not usable.
- "Quality does not decrease" during a Sprint.
- The Sprint Retrospective is used "to plan ways to increase quality and effectiveness". If quality doesn't decrease in a Sprint and the Retrospective increases quality, there's an implication that between two consecutive Sprints, quality remains at least the same if it doesn't increase.
I'm not sure what you mean by asking if we change our Definition of Done to include more strict quality rules like test code coverage, know bugs, and performance. I've always encouraged the Definition of Done to include these aspects, and I believe many others do as well. The exact criteria depends on the context - some work (like some aspects of performance and security testing) is more suitable to a whole system rather than individual units of work, but there are ways to incorporate them at the Product Backlog Item level as well.
My thought was that the change to usable actually made it more strict. For example, something could be potentially releasable by putting unfinished work behind a feature flag. But something that would not meet the definition of usable.
All of the Definitions of Done that teams I have been involved with prior to the 2020 revision are still in use as is. They already had statements like you referenced if a team felt they were necessary to be included. Remember that the Definition of Done is used to communicate to anyone outside of the Scrum Team what is meant when that team says "we are done". I have always encouraged that it should contain anything that they would expect other teams to commit to as well. That has lead to a lot of very similar Definitions of Done. In some cases it has almost created an organizational definition that is then customized in an additive way to be specific to the product under development.