Scrum - A Pocket Guide (Best Practice (Van Haren Publishing)) by Gunther Verheyen

Author:Gunther Verheyen [Verheyen, Gunther]
Language: eng
Format: azw3
Publisher: Van Haren Publishing
Published: 2013-10-01T04:00:00+00:00

2.5.5 The importance of done

In a definition of ‘done’ the conditions are expressed that need to be met by an Increment of product in order for it to be ‘shippable’. It is an overview of all the activities, criteria, tasks and work that need to have been performed on a working piece of software in order to be able to release it into production.

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.

The prefix ‘potentially’ is, however, added to ‘shippable Increment’. This refers to the Product Owner’s accountability to decide upon the actual release of an Increment; a decision that will likely be based on business cohesion and functional usefulness as observed during the Sprint Review. Yet, the Product Owner’s shipping decision should not be constrained by ‘development’ work, hence all work required to achieve the level of done is performed before the Sprint Review meeting in the Sprint.

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 should be known by all players. Transparency means not only visible, but also understandable. The content of the definition of done should be self-explanatory.

Through the definition of done, quality is at the heart of what Scrum Teams do. No undone work is part of the Increment. No undone work is put into production. Ever. From the inspection of the Increment based upon the definition of done at the Sprint Review, the collaborative conversation might include quality, and requirements with regards to the definition of quality in the organization. This helps the team consider the definition of done at the subsequent Sprint Retrospective. The self-organizing drive of the Development Team will include all that’s actually possible, and more, take into account the feedback from the stakeholders.

Primary ownership of the definition of done lies with the Development Team, in the same way that primary ownership of Product Backlog lies with the Product Owner. The Development Team does all the hard work related to delivering working software that complies to the definition of done. A definition of done can’t be forced upon a Development Team. Neither can it be cut short by forces outside of the Development Team. The Development Team will include its own development standards and will obviously incorporate the functional or business quality expectations from the Product Owner. The Development Team will also include general, organizational expectations and compliance (from the development, engineering, quality or operations areas).

Decisions over the definition of done will depend on the presence of the skills, authorizations and availability of external systems, services and interfaces. Although dependencies are typically managed via ordering of the Product Backlog, a Development Team prefers to make progress. The team is likely to include stubs and simulators for non-available systems or non-resolved technical dependencies.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.