Scrum brings agility to and creates Agile organizations through the implementation of empirical process control, the process of frequent inspection and adaptation. The empiricism of Scrum serves discovering and taking advantage of opportunities and options, at all levels; people, technology, market.
If Scrum, as a product development framework, was to be reduced to one purpose, and one purpose only, that core purpose would be the creation of releasable Increments of product. Frequent releases of Increments of product are the ultimate way to close the feedback loop with markets and customers, to inspect market reception, to validate all assumptions built-in into the product, to check on the ROI (understanding that 'return' might be expressed in more than financial terms only). The goal of a release is to adapt to reality, remove biased concepts and ideas from the product, overcome previously groundless presets and expectations, improve ROI, even stop further development. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility, blocks adaptation to reality, invites to get out of sync with reality.
The term in Scrum to describe the state of software being releasable is "Done”. Everything that the state of being releasable covers is captured in the "definition of Done”. The purpose of creating releasable Increments thereby puts "Done" and what it is that defines "Done" at the heart 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 is best shared, made explicit, clear and concise. The definition of Done guides many activities in Scrum.
- A Development Team will use the definition of Done to consider the amount of Product Backlog 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 identification of what is important to do next, not hindered by unknown, unpalatable remaining work that is near-impossible to estimate.
- 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 professional accountability to develop software that can be released. In many organizations the definition of Done is likely to be derived from organizational standards for product quality. A Development Team will enact them, expand them. If "Done" is not a convention of the development organization, the Development Team will create their definition, appropriate for the product being developed.
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. What are situations in which undone software is consciously released? An extreme crisis maybe? The least to do then is to make the undone work transparent via Product Backlog, knowing and understanding that the nature of the work makes it unplannable by default and any estimate of such corrective work is probably totally off as a result. Plus, such '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, let alone delight customers. Unreleases backfire.
The importance of Done
Regardless the representation or format, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.
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. 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.
Done is at the heart of Scrum.