If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. The typical term in Scrum to describe the state of software being releasable is “Done”. All that this state of releasability encompasses is captured in the “definition of Done”.
Done Increments are THE way to achieve agility through the empiricism of Scrum.
Empiricism
The empiricism of Scrum, the process of regular inspection and adaptation, only functions well upon transparency. Transparency is having insights into reality but is is additionally upheld through standards and agreements, against which inspection and adaptation happens. The definition of Done is such a standard. The definition of Done is part of professional Scrum development. Other standards, like development and engineering standards, might even be derived from the definition of Done.
The frequency of the inspection and adaptation should be high enough to be able to act in the moment yet not too high to preserve the ability to get considerable amounts of work done.
The definition of Done serves empiricism
The definition of Done should be shared, explicit, clear and concise.
A Development Team will use the definition of Done to consider the amount of work to be pulled into a Sprint during Sprint Planning.
The evolution of an Increment is managed via collaborative inspection and adaption of the actual development work against the forecasted Product Backlog and the Sprint Goal; at least on a daily base, possibly sooner. A Daily Scrum assures that the people accountable for the actual development optimize their work plan against new insights and achievements. The definition of Done supports identification of work remaining to get the software to “Done”.
No later than at the Sprint Review, the Increment is collaboratively inspected and adapted with the stakeholders. This inspection opens up the opportunity of incorporating feedback from these stakeholders to identify what is most important to do next. Purpose is the open identification of what is important to do next, not hindered by unknown, unpalatable, unestimatable remaining work.
Releasing the software closes the feedback loop to the market and the users of the software. Releasing sooner is better in order to remain in line with external expectations and experiences. It is the only way to ultimately validate all assumptions (of functionality, and others) built into the product. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility. The decision of releasing an Increment by the end of a Sprint is a Product Owner decision, as the sole representative of users and stakeholders on the Scrum Team. The Product Owner’s shipping decision should not be constrained by ‘development’ work.
Undone software is best not released. There might be situations in which undone software is consciously released. An extreme crisis maybe? The least to do is make the undone work transparent via Product Backlog, knowing and understanding that any estimate of such corrective work is probably totally off and the nature of the work unplannable. This ‘registration’ does not render an undone release any more professional, and probably the crisis you are hoping to solve with the unrelease, will re-appear because an unrelease will not fundamentally solve it. Unreleases backfire. Probably better to Scrumble.
At the Sprint Retrospective, the Development Team might inspect and revise its definition of Done; incorporating new insights, new expectations, higher standards. Ownership over the Definition of Done lies with the Development Team. It is their accountability to develop software that lives up to the definition of Done. In many organizations the definition of Done is likely to be derived from organizational standards for development quality. A Development Team will enact them, expand them. If “done” for an increment is not a convention of the development organization, the Development Team will create their definition of Done, appropriate for the product.
Regardless, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.
Done is a crucial part of Scrum, actually
Although no official artifact, the definition of Done is a crucial part of Scrum in upholding transparency over the state of releasability of the software created. No transparency means no meaningful inspections, and no meaningful adaptations of Product Backlog through stakeholder feedback upon review or through user feedback upon release.
In the last updates to the Scrum Guide (most recent: July 2013) the definition of Done was given considerably more attention. Rightfully, as “Done” is absolutely crucial in Scrum.
Here’s how I stressed the importance of Done in my book, “Scrum – A Pocket Guide“:
The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.
and
The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.
[…] die Kombination von Scrum mit agilen Praktiken und über das Verständnis von "Done" und […]
[…] Done is a crucial part of Scrum, actually […]
[…] basis of empiricism, of business agility. Imagine my surprise that this was not even mentioned, THE core purpose of […]
Good one! Gunther what are your thought on product owner challenging the team on the doneness of the product increment.
Why the need to challenge, Sachin? What about having a transparent definition of Done, and the Product Owner and the Development Team collaborating on it?
[…] Done is a crucial part of Scrum, actually […]
Without a Definition of Done, there’s is no transparency. As simple as that.
When your product increment is not potentially shippable (at the end of the sprint), you need to expand your definition of done. Any undone work increases risks, and will be a source of delay when you want to release your product to the market. Furthermore, the “undone” work will pile-up. A good Product Owner wants a perfect Definition of Done.
Clarity in demonstrating definition of done related to transparency and feedback for adapting how else to improve in the next sprint.
Very clear definition of “Definition of Done”. I found a lot of people are still confused the difference between Definition of Done and Acceptance Criteria. I will use this article as a reference. Thanks Gunther.