In order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used. In simple terms, Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. It includes a comprehensive checklist of necessary activities that ensure that only truly done features are delivered, not only in terms of functionality but in terms of quality as well. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts. The DoD may vary from one Scrum Team to another but must be consistent within one team.

There might be different DoD at various levels:

1. DoD for a user story (e.g. writing code, tests and all necessary documentation)

2. DoD for a sprint (e.g. install demo system for review)

3. DoD for a release (e.g. writing release notes)

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 :

1. Can we do this activity for each feature/story? If not, then

2. Can we do this activity for each sprint? If not, then

3. We have to do this activity for our release

Story Definition of Done

What must happen for the story to be marked as complete:

• All story should have an automated acceptance test.
• The story should have working code supported by a unit test that provides around 60 – 70 per cent 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

• The 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

• The product is deployed to the test-box and makes it to the 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.

The Evolving Definition of Done

A team’s Definition of Done won’t remain the same throughout the lifetime of the project and neither should it. As the team becomes more effective and productive and learns to work better, it will naturally enhance and refine its Definition of Done to produce more valuable and better quality features. It will start recognising patterns in the development processes and procedures required to produce high-quality features, and it’ll start adding these to the DoD. It’s therefore important that the team gets regular opportunities to revisit the Definition of done and the natural place to do this is in the sprint retrospective meeting.

Definition of Done common impediments

Some of the common root causes of the impediments are:

• The team does not have the skill set to incorporate activities into the definition of done for a sprint or for a feature.
• The team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
• Team members are executing their sprint in mini-waterfalls. Aha! Opportunity to be more cross-functional. Sharing of responsibilities across functional silos.