Describe the Importance of Done Meaning Usable
I'm wanting to level up my coaching on the subject of the Definition of Done. I'm currently coaching a team that wants to expand Done to mean "In Production." The 2020 Scrum guide is less clear to me than the 2017 version which used the phrase "potentially releasable" to represent an increment.
Here's how I understand the arguments supporting the proposition: Done should mean potentially releasable and should NOT mean "in production" or "released for general use."
Flexibility is Valuable
Done should mean usable increment is technically releasable. This allows the business to decide when that increment would best be delivered to users. This is valuable due to the increased flexibility of loosely coupling technical completion and strategic release.
More Dependencies is More Worser
Concomitantly, tightly coupling Done to being released would introduce an external dependency into a Scrum team's backlog items i.e. dependency on the business to choose to release a given backlog item as part of a given increment. This of course may not occur or may not occur often yet would follow directly as a structural dependency.
Definition of Quality Measure Congruent with Common Usage
Another direct consequence of this tight coupling would seem to be expanding the definition of "quality measures" to include "being deployed" which doesn't seem to me to be a measure of quality. I cannot think of a product that is thought of as "high quality" because it has been released.
Your Turn
Is it important that Done mean "could be released to users" as opposed to "already released to users?" Why?
Once an Increment is Done, the imperative is to make it available for use, and to obtain empirical feedback. The business do not therefore "choose" to make a release. The Developers may reasonably make this decision, since they are accountable for determining whether or not an Increment is Done and in a usable state.
The Product Owner can stop a release from happening, if for some reason it is inappropriate to do so for business reasons.
"Release" does not necessarily mean putting an Increment into production, even though it must be of that quality, with no work remaining to reach that standard. The important thing is to put it into an environment which is empirically fit for purpose, and which thereby allows the validated learning loop to be closed.
Instead of a universal idea of what Done means, it's important to define it for your specific context. Even if you narrow down the scope of the conversation to software development, there's a wide range of what is possible for a team to achieve.
At one point, I was a software engineer working on embedded software for a complex electro-mechanical system that was used on aircraft. Components - mechanical pieces, electrical pieces, software - had to be designed, built, and tested. Then, the modified components had to be integrated onto a very expensive, very rare system. Then the updated system had to be tested in a lab setting, followed by flight testing. And only then could existing systems be modified to use that configuration or new units using that configuration be built and fielded. Even if we considered "released to users" to mean "released to the team that does lab testing", the fact that the final verification needed to be done on a real system meant that work wouldn't be done often. Instead, we considered "done" to mean passing as much testing as possible using simulators and emulators, and we invested a lot of time in software tests and building out ways to simulate hardware devices. The intention was that software defects found in the lab should be rare, and defects found in flight testing and in the field should be even more rare.
The idea of "done" meaning "released to users" may work very well in some lines of business software. But even careful consideration of who users are, and broadening consideration to some downstream stakeholder group, could make it very difficult to get work to a Done state. Getting the work to a state where it could be released to some downstream user and go through the next steps in the process may be the best that some teams can do. The important thing is to not only maintain, but enhance, the quality of your product by enhancing your Definition of Done and the tools used to assert it.
I'm wanting to level up my coaching on the subject of the Definition of Done. I'm currently coaching a team that wants to expand Done to mean "In Production.
Done is generally used at a lower environment and not production. However, in some teams a sprint (of one month) always has a release to Prod and stories/ backlog items are marked as done and closed out only after Prod deployment.
In other cases, there may be quarterly releases (or on demand releases) and in this case Stories are marked Done once tested and approved in QA (here the sprint timebox will be lesser 15 days or so).
If you go by CI-CD pipeline a piece of software is deployed on a staging environment from where it can be moved across QA or Prod. Once tested and approved on QA the code is good to be deployed on PROD and that is when it is done. It may be released at a later date, but it is Done and available to release to Prod as and when the required.
I have worked with teams where their "done" included being in production. They also had a corporate requirement that everything that was newly promoted to production had to be behind a "feature flag" so that it could be turned on/off quickly or released to a select body of users. This allowed them to get new work into production where the feedback loop could begin but allow it to be done safely.
Having "in production" as part of "done" has caused some real issues for other teams I have worked. What if there are other teams attempting to push out changes that could impact the new code your team wants to push. For example, the infrastructure team pushing out some upgrades to compilers or container versions. Or the DB team doing some updates to the data structures or version. As a Scrum Master, I would ask them to think of circumstances that could stop them from being able to push out changes and have them consider if they really want to include "in production" in their definition.
Lots of good feedback. Thank you all! I'll ask a follow-on question to Ian:
Would you agree with these definitions?
Releasable - of the quality specified in the Definition of Done, with no work remaining to reach that standard.
Release - to put it into an environment which is empirically fit for purpose, and which thereby allows the validated learning loop to be closed.
Yes, although I generally avoid using these terms, because I know others have different views as to what constitutes a release environment. As long as it is empirically fit for purpose, the semantics of what "release" or "releasable" means is not a hill worth dying on.
It is perhaps better, on the whole, to talk about the usability of an Increment, and this is the language preferred in the Scrum Guide.
Thank you, Ian, I think we're getting somewhere! Sorry in advance to sound so pedantic but this seems important to me. The SG relies on both terms -- usable and released. An increment must be usable. As soon as a backlog item is Done, a (usable) increment is born. A product backlog item cannot be released unless it is Done. Usable and released seem to be in a tight, logical relationship.
The logic seems to be as soon as a backlog item is Done it should be usable. At some point after it is part of the Increment, it may be released (whatever that means). I think it is important to answer this question next:
Does "usable" mean theoretically usable or actually usable? (ducks) Let me describe how I picture the distinction I'm pondering.
Scenario A. Imagine I make teapots as my product. Each is custom-made to satisfy a single customer's purposes. After shaping, painting, firing and testing the teapot, I decide that I believe my customer could do what he needs to do with it and his expectations of my work will be fulfilled. I believe it is theoretically usable though my customer has not actually used it. Perhaps I consider it Done at this point and plan to release it to him tomorrow when I see him.
Alternatively in scenario B, I may decide I won't consider my teapot Done before the teapot is released to my customer's kitchen counter. In that state, he could actually use the teapot as soon as he desires a cup of Darjeeling.
In Scenario A, I can control when the teapot is Done. In Scenario B, I cannot. After all my customer may go away on business for a month leaving me with a work in progress until he returns.
This is important because the Scrum team are responsible for producing a usable Increment each Sprint. It would seem internally inconsistent for Scrum to imply the Scrum team is to be accountable for creating (at least) [one] valuable, useful increment each Sprint if they are not also in control of when their Increment is considered Done.
But, if Done means not necessarily released (a Scrum guide term) and qualified to be released , this gets much simpler.
In Scenario A, I can control when the teapot is Done. In Scenario B, I cannot. After all my customer may go away on business for a month leaving me with a work in progress until he returns.
If he can leave work in progress, and his industry is needed for that work to be finished, then your customer is by definition one of the Developers as well. He may not realize it, but he is. He shares in the accountability for work being Done, just as surely as other Developers do. The absence of that Developer would be the problem to solve.
Forgive me, but this seems a bit confusing. If my customer cannot yet use my teapot i.e. I am blocked from releasing it, my work cannot be Done and my customer should realize he is actually a Developer because he couldn't receive his teapot as soon as I could have released it to him?
Moving away from teapots, I'll choose a software example to try to grok what you're saying. I'm a Product Owner with a vision for a new betting feature on my sports betting website. This feature will allow users to place bets on how many times the camera will cut away to Taylor Swift in the audience. I want to time the release of this feature for 3 days before the SuperBowl to coincide with a marketing blitz campaign. My Scrum Team colleagues create to a Sprint Goal for the Sprint ending 7 days before the SuperBowl. They create a high-quality Increment. It meets my conditions of satisfaction, it goes through rigorous automated testing, performance stress testing, and even a little exploratory testing. We deliver it to production behind a feature flag that will remain turned off for 4 days until it is turned on in perfect timing with our ad campaign.
Here are two possible Definitions of Done that my Scrum team could choose:
DoD #1
- All tests pass.
- PO agrees backlog item is fit for purpose.
- has been deployed to production. It may be "turned off" with a feature flag or it may be "turned on" so that uses may actually use it.
DoD #2
- All tests pass.
- PO agrees backlog item is fit for purpose.
- has been deployed to production. It must be "turned on" so that users may actually use it.
With DoD #2, the Scrum team fails to achieve its Sprint goal, not because of any issue of scope, quality, or hypothetical usability, but because there is a strategic business reason to delay when end users should access the functionality.
This seems to be a big divergence from the 2017 Scrum guide which stated, "The increment must be in useable condition regardless of whether the Product Owner decides to release it." I don't find a mention of this shift in the "Changes between 2017 and 2020 Scrum Guides" information.
Is it true that the distinction between "Done" and "released" has been eliminated? This would seem to be what you are implying.
Think of "Done" as potentially releasable. We're always after something that is "Done" every Sprint for transparency and to ensure we have not cut any corners (e.g. skipped writing unit tests, didn't have a code review, didn't refactor code to remove tech debt, etc.). The earlier a problem is found, the cheaper it is to fix.
"Done" doesn't have to include "released to production". It could mean "deployed to production, toggled off, and validated". It could even mean it was "deployed and validated in the highest test environment", yet we've all seen minor differences in product and test environments causing a back out.
DoD #1 is a good start, but does the product scale? Will it work on various devices, browsers, etc? Has documentation been delivered, if needed? Are SLAs met? Is the code maintainable and tech debt removed?
Neither of those DoDs would be good, because both require the PO to agree that a deliverable is fit for purpose. That's a quality decision which the Developers are accountable for.
The PO is accountable for value, and can stop a release from happening if the value of doing so is no longer there.
Anyone who shares accountabilty for quality is a Developer. If quality is determined to be inadequate after Done work is made available for use, you have not therefore necessarily discovered a new Developer, because accountability has not changed, but you will have discovered technical debt. In other words, the Developers might be Done and still build up debt in the Product. The Sprint Retrospective provides a formal opportunity for quality to be challenged and improved by those who are accountable for it.