Definition of Done is an agreement between Development Team and the Product Owner on what needs to be completed for each user story so that it can be satisfactorily verified and validated – usually in the form of a clear and concise list of acceptance criteria that a software Increment must adhere to for the team to call it complete. Until this list is satisfied, a product Increment is not done. It is often standardized across the company in order to guarantee consistent delivery of quality. The Scrum Guide describes the Definition of Done (DoD) as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality.
Builds a common understanding within the Team about Quality and Completeness.
Use as a checklist that User Stories (or PBIs) are checked against.
Ensure the increment shipped at the end of the Sprint has high quality and that the quality is well understood by all involved.
Dependencies:
The nature of the product being developed.
The technologies being used to develop it.
The organization that is building the product.
The present obstacles that impact the possibility.
Things to consider:
Review Acceptance Criteria
Gather the Acceptance Criteria for work completed so far.
Look for common criteria that can be abstracted out and applied across work in general.
Use these common criteria as the basis for a Definition of Done.
Assess Technical Debt
Identify any rework that needs to be done.
Identify the reasons why it wasn’t done properly the first time.
Identify what measures can be put in place to stop similar rework from occurring.
Add these measures to the Definition of Done (DoD).
Continually update the DoD
In each Sprint Review, identify which (if any) work was rejected or which caused rework to be done, then
In each Sprint Retrospective, challenge the DoD for relevance and completeness
Things that commonly addressed in the Definition of Done are:
Operating environments and at what level of integration are user stories expected to work?
What level of documentation is required?
What are the quality expectations?
What are the security expectations?
Scalability expectations?
Advantages:
Having a clear Definition of Done helps Scrum Teams work together more collaboratively, increases transparency, and ultimately results in the development of consistently higher quality software.
During the Sprint Planning meeting, the Scrum Team develops or reconfirms its DoD, which enables the Development Team to know how much work to select for a given Sprint. Further, a common DoD helps to:
Baseline progress on work items
Enable transparency within the Scrum Team
Expose work items that need attention
Determine when an Increment is ready for release
The Definition of Done is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.
The adoption of DoD happens during Sprint Retrospective
When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of “Done” for all teams, because they might be working on items of different natures.
In such a case, each Scrum Team will define its own definition of “Done” and delivers its items based on that definition.
However, the integration of those definitions of “Done” should be capable of creating a potentially releasable Increment in the project level.
There are various factors
which influence whether a given activity belongs in the DoD for a feature, a
sprint or a release. Ultimately, the decision rests on the answer to the
following three questions:
Can we do this activity for each feature/story? If not, then.
Can we do this activity for each sprint? If not, then.
We have to do this activity for our release.
Story Definition of Done
All story should have automated acceptance test.
The story should have working code supported by unit test that provide around 60 – 70 percent coverage.
The story should have well defined acceptance criteria.
The code must have been written as a pair or should be code reviewed.
Code must be completely checked in to the source control system and the build should pass with all the automated tests running.
The product owner must accept the story.
Sprint Definition of Done
Product owner should have defined a sprint goal.
All stories completed for the spring must be accepted by the product owner.
All the automated acceptance tests should be running for the stories in the sprint.
All code should have been pair programmed or must have gone through a code review process.
If there is a database involved, the database scripts must have been automated and tested.
Release Definition of Done
Product is deployed to the test box and makes it to staging.
There are deployment documents for the release.
Training manuals are available for users.
All stories for the release are completed and accepted.
The release does not have any level one bugs.
Sample DoD Checklist
All code has been written and all to-do items are complete.
All code has been tested and passes quality standards.
All code has been checked in and run against current version in source control.
All code is free of errors and functions in every operating system or browser.
All code has gone through an architecture review.
All code has gone through user testing and/or a usability assessment.
The feature developed satisfies the requirements documented in the user story.
The product owner has accepted the feature.
The feature has been documented in any end-user documentation.
The feature has been documented in any internal documentation.
Summary
The DoD is a very
important concept in Scrum. It helps to have a common understanding of what
work needs to be done before a user story is considered “finished”, it is a
place for process improvements and it holds non-functional requirements. You
should keep it minimal or you will hardly ever get something done in a sprint.
Some teams have embraced the notion of ‘done’ vs ‘done-done’. Done-Done is supposed to be more done than just done in some ways. Teams use this term to convey that the task performed during the Sprint is really done. The task is done to the point that the customer could think that the work is ‘done’ (potentially shippable product).
The Scrum teams that use ‘done-done’ to convey “we performed as much work as we were prepared to do!” But the fact is well-performing Scrum teams don’t need those two concepts to exhibit their performance. For such teams ‘done’ really means ‘done-done’.