... a member of the team demonstrates to the Product Owner a Product Backlog Item that has just been “completed.” When the Product Owner asks the Development Team when the feature can be used, she is told that it still requires additional testing and system migration, which in turn depends on another task. Continuing the discussion, another team member says that because it is an essential piece of the system they should review it before release. “So when is it completed?” asks the desperate Product Owner. “You just demonstrated it, but there are still things that should be done.”
✥ ✥ ✥
Each team member may have a different understanding of “work completed” for the team’s deliverables.
During the Sprint Review the Product Owner needs to understand where development stands in terms of progress so that she can take informed decisions about what to work on in the next Sprint. She needs to know which issues need attention, and needs input that will help her keep stakeholders informed. The more transparent the increment is to her, the better she and stakeholders can inspect it and take appropriate decisions. 
For one, “complete” may be when work is documented, reviewed and having zero known bugs — for another, it may be “complete” when it does not break during light exploratory testing. This discrepancy may cause varying degrees of quality in delivered work.
The teams should be able to deliver a Potentially Shippable Product Increment at the end of the Sprint. If the quality is lower than expected by the stakeholders, the team should not view the increment as being releasable. Consequently, additional time might be required for stabilization, testing and bug fixing. But if the Sprint is over, time is out.
Uneven work quality and unexpected delays may draw blame towards the team and also create tension within the team. To really make a team, the people in it have to work together and this requires that they be aligned with respect to quality.
It’s not just about stuff that’s externally visible, but rather about anything that could be of value to any of the stakeholders, including the Development Team itself. For example, software source code that follows coding standards will cause developers less frustration when they work with it in the future.
It’s easy for the team to unconsciously (or even consciously) hide the fact that they have skipped conventions of consistency or quality. However, this creates technical debt, which must be paid sooner or later. While external product attributes will become visible in the Sprint Review. It’s important to have a standard for these internal items even if you trust the team to do its best.
All work done by the Scrum Team must adhere to criteria, agreed between Developers and the Product Owner, which collectively are called the Definition of Done. Done means that the Development Team has verified that there is no known remaining work with respect to these criteria. If the work does not conform to Definition of Done, the work is then by definition not Done, and the corresponding PBI cannot be delivered.
It is stupid to include items in the Definition of Done that fail to increase value for any stakeholder — remembering that Developers, too, are stakeholders.
The perfect Definition of Done includes all work that must be completed to release the product into the hands of the customer. Scrum Teams start with a Definition of Done that is within their current capability and work on strengthening it over time. A more complete Definition of Done gives a more accurate insight into development progress, makes development more effective and ensures you end up with fewer surprises in late stages of development.
Work that needs to be done but is not yet included in the Definition of Done is placed on the Product Backlog. When for example internal architecture documentation is not in the Definition of Done it is placed on the Product Backlog to be done at a later time. Once user documentation is done the Scrum Team can decide to add user documentation to their Definition of Done. This would mean that user documentation is up-to-date in all subsequent Sprints.
The Sprint Retrospectives are an occasion suitable for reviewing and enhancing Done, but the definition can be revisited any time the team sees it necessary or desirable. The ScrumMaster should challenge the team to periodically tighten up “Done;” see Kaizen Pulse. This facilitates team growth as they raise the bar for themselves.
The Scrum Team owns its Definition of Done, as otherwise it could be hindered with fixed definitions without any way of improving them. The ScrumMaster enforces the Definition of Done. Scrum Teams generally create their initial Definition of Done based on how they currently operate, with a careful review of what demonstrably adds value.
An understandable, clear and enforced Definition of Done creates a shared understanding and common agreement between the Product Owner and the Development Team. This reduces the risk of conflict between the Development Team and the Product Owner. The Product Owner can be assured that no additional work is necessary to deliver work at the end of the Sprint such as an additional stabilization period. The Scrum Team should explore whether some kinds of hidden work should be added to the Definition of Done.
Each criterion in the Definition of Done should be objective and testable. The objectivity and testability are well demonstrated by this good old parenting example: A father asks a child: “Did you clean your room?” The child says yes. Then the father continues: “Are the toys put away, clothes hung up, bed made and floor vacuumed? ”The child says no. So, do not test for activity but rather for concrete result state. This makes it also easy to formulate Definition of Done as a checklist. Contrast this with Testable Improvements, which applies more to process kaizens; most elements of Done are properties of the product.
Encountered technical debt should be removed or at least reduced when team encounters some old work, which does not adhere to the current Definition of Done. Typically only the area near the modification is cleaned up to limit the scope of change to a reasonable size. In the long run, Definition of Done helps to remove technical debt.
In larger organizations, a shared Definition of Done across all teams might establish a common quality level. Balance the idea of a shared Definition of Done against the need for team autonomy. In case multiple Development Teams work on a single product they all share the same Definition of Done as they deliver a single integrated Product Increment at the end of a Sprint.
The team does not create a custom Definition of Done for each PBI, but rather applies a general set of criteria. However, such a single set of criteria does not always match all work items well. For example, criteria for documentation, calculations and code could different. If you have wide range of varying types of work items, which a single set does not cover adequately, you will have separate Definition of Done for those types of work items. This is quite common.
✥ ✥ ✥
With a discipline regularly of achieving Done, the Scrum Team is in a position to deliver Regular Product Increments of known quality. Just practicing Good Housekeeping can keep a team from getting in trouble with technical debt. As a consequence of each PBI being Done each Sprint, there are no “quality PBIs,” “quality Sprints” or “hardening Sprints.” Chances of having unpleasant surprises let in development are minimal and progress during development is reliable. Having a hard Definition of Done eliminates the need for, for example, development operations (DevOps) teams that configure releases for clients, which eliminates handoffs in a way that is in line with good lean practice.
A good Definition of Done captures the recurring required tasks that appear in multiple PBIs in multiple Sprints. Having one fixed, common list avoids having to repeat these items as PBI expectations or SBI activities.
With a good Definition of Done, the team will avoid technical debt. Add the Definition of Done to the criteria the Product Owner uses to approve a Product Backlog Item in the Sprint Review. Good ScrumMasters challenge the Development Team to adhere to the agreed Definition of Done; the Product Owner enforces compliance with externally facing requirements, communicated in Product Backlog Items as Enabling Specifications. The Product Owner will allow only Done PBIs to be delivered and should choose to let only Done PBIs into the Sprint Review demo. There are some grey areas, such as user interface guidelines (think Apple Interface Standards), which are outward facing but which can be automated and potentially put under the purview of the Development Team.
Robert Stephenson Smyth Baden-Powell, the father of Scouting, was “Try and leave this world a little better than you found it.” Today, Scouts say, “Leave the campground cleaner than when you found it.”  The same applies to leaving the product and shop floor cleaner than they were when you started.
 Ken Schwaber. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004, p. 71.
 Lord Baden Powell. BiographyOnline.net, http://www.biographyonline.net/humanitarian/baden-powell.html (accessed 1 November 2017).
Picture from: The Scrum Pattern Group (Ville Reijonen).