What does Definition of Done mean in Agile?

Definition of Done can be defined as a collection of important activities that adds provable / definite value to the product.

The activities include coding, writing comments, unit testing, integration testing, release notes, design documents etc. Focusing on value added steps would allow the team to eliminate unwanted activities which complicate the efforts of software development.

For the teams who work for potentially shippable products, the Definition of done would contain the subset of deliverable which is needed to release to the end users. Such teams have 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 many factors which influence if the given activity would belong in DOD for a feature or for a sprint. The team must most importantly answer -

• Can we do this activity for each feature? If not, then
• Can we do this activity for each sprint? If not, then
• We must do this activity for our release!

For the activity which we will not be delivering in the current sprint, all the obstacles that have encountered and due to which they could not be delivered would be discussed.

DOD is not Static -

DOD changes over time. Organization support and the team's ability to remove the impediments would enable the inclusion of activities into the DOD for a sprint.

Definition of Done Components

In Product Development, DOD has three main components -

• Business or Functional Requirements
• Quality
• Non-Functional Requirements

Business or Functional Requirements

This is the standard business requirement that is assumed to carry value in the Product as functionality and this can also be written in the form of User Stories and it carries acceptance criteria as well.

Quality

Quality is largely aligned to the coding language/Rapid Application Development (RAD)/technical tools in order to build the Product. Quality is owned by the Development Team to ensure that the product is of the maximum quality. These quality standards would be subjective, and also data driven.

Non-Functional Requirements

These are the standard characteristics or attributes of the Product which might not add direct business value but without which your Product cannot move. These quality assurance attributes of the Product would be considered as the quality component too.

For example -

• Availability
• Maintainability
• Performance
• Reliability
• Scalability
• Security
• Usability
• Compliance/Regulatory
• Legal

DOD is an Auditable checklist

During the sprint, a big task would be broken down into small parts. DOD is used to validate whether all the major tasks are accounted for. After a sprint is done, DoD would be used as a checklist to verify whether all the necessary value-added activities were completed applies only to a comprehensive checklist of activities. The team should consciously decide about applicability of value-added activities for each feature.