Template builder - Plugin Template

Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of Done is critical because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms. This clear definition is used to create the Done Criteria when a Prioritized Product Backlog is prepared. A User Story is considered done when it is demonstrated to and approved by the Product Owner who judges it on the basis of the Done Criteria and the User Story Acceptance Criteria.

Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well.

DoD is a checklist of valuable activities required to produce software.

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. 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.

DoD is the primary reporting mechanism for team members.

Reporting in its simplest form is the ability to say, “This feature is done.” After all, a feature or Product Backlog Item is either done or it is not-done. DoD is a simple artifact that adds clarity to the “Feature’s done” statement.  Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner.

DoD is informed by reality.

Scrum asks that teams deliver “potentially shippable software” at the end of every sprint. To me, potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion. Products that can be released to end users with two days can be reasonably said to be in potentially shippable state. Ideally, potentially shippable is equivalent to the Definition of Done.

In reality, many teams are still working towards a potentially shippable state.  Such teams may have a different DoD at various levels:

• Definition of Done for a feature (story or product backlog item)
• Definition of Done for a sprint (collection of features developed within a sprint)
• Definition of Done for a release (potentially shippable state)

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? If not, then
• Can we do this activity for each sprint? If not, then
• We have to do this activity for our release!

For activities that cannot be included for a sprint/feature, teams should, “Discuss all of the obstacles which stop them from delivering this each iteration/sprint”

Common root causes for impediments include:

• Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature.
• 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.