Gunther Verheyen

Teams and organizations want to capitalize on business and market opportunities. Scrum offers them this option by assuring a “Done” Increment—i.e., a releasable version of product is available no later than by the end of each Sprint. As a Sprint takes no more than four weeks (and often less), the organization can be faster to market, win an opportunity, and generate value.

Without making transparent what Done encapsulates, Scrum cannot be applied effectively. Via a definition of Done, everyone understands what Done means. This is vital when considering the opportunistic value of the product functionality offered in an Increment. The definition of Done also provides crucial clarity for the Development Team when forecasting work deemed feasible for a Sprint. Throughout a Sprint, the definition of Done guides them in assessing whether work on Product Backlog items and the product Increment is complete.

A professional organization only releases Done Increments; Scrum professionals adhere to the definition of Done. Always. No “undone” work is part of an Increment. No undone work is put into production. Ever. Committed professionals reflect on ways to improve product quality as reflected in the definition of Done.

Many teams across the world seem to be unable to create Increments of product that are actually releasable. Code is entered, and potentially tested, within a team. But the actual Increment remains scattered and hidden in long-lived branches. Or the work delivered at the end of a Sprint still needs to be integrated with the work of other teams. Or—even worse—it needs to be shipped to a different department for that purpose. In those cases, Scrum reveals that there are important organizational dysfunctions impeding the organization’s agility. There is a substantial amount of “Undone Time”: the time it takes to go from an undone piece of work to a Done Increment. This wasteful delay kills the option of opportunistic releases.

The purpose of a Sprint in Scrum is not just to result in a piece of work that can be shipped to another team, functional group, or department. An Increment is expected to be in a usable condition, ready for production. An Increment should be, at minimum, in a production-deployable state. The definition of Done describes that state.

Most often, teams include in their definition of Done the development activities to be performed for an Increment to be considered “releasable”: pair-programmed or code-reviewed; unit-tested; user acceptance–tested; integration, regression, and performance–tested. These are great development standards that enhance transparency, but are they also a great definition of Done? Imagine any non-software industry. Can you imagine “quality” being expressed in terms of the machines, tools, and practices used? Is this not how to create quality, rather than defining quality itself?

Quality is optimally defined through the qualities the product should exhibit. A Done product in Scrum is not just a product on which rigorous, proper development standards were applied. A Done product exhibits the product qualities your organization envisions: the product’s interior construction and the organizational and maintenance standards and conventions respected, with valued functionality only and living up to all applicable usability standards.

Capture in your definition of Done more than the work needed to produce a releasable Increment. Shift it toward guiding you in creating valuable Increments.