Getting things done differs per person.
For some, it is about the minimal effort for minimal results; for others, it is about hard-work and high achievements.
It is already challenging to align people on concrete deliverables like when building a house or cooking a meal.
It is even more complex for software.
Different perceptions lead to all sorts of waste building software: overwork, waiting-time, defects, rework.
Teams able to systematically consider software changes as completed with minimal effort can deliver continuous software increments.
This article covers the need and guidelines to start building such Quality Engineering capability for Quality at Speed software.
Follow the QE Unit for more Quality Engineering from the community.
What is the Definition of Done (DoD)
Agile methodologies define the Definition of Done as a formal description enabling to consider software changes meeting the quality requirements for a product.
The key aspect of DoD is to be:
- Aligned on company values
- Adapted to specific tasks
- Shared with the team
- Systematically performed
- Clear and concise requirements.
Concretely, an organization putting customer privacy as a key differentiator of their value proposition would add this requirement in their DoD.
The Definition of Done therefore contains a core checklist of quality attributes then adapted in different task templates.
It is equally important to differentiate what DoD are not:
- The scope of work
- The acceptance criteria
- The delivery of increments.
Implementation details are checked against DoD, while verifying the prerequisites for starting to work on software is a similar yet different concept, the Definition of Ready (DoR).
Now, what to do with DoD in Quality Engineering?