What is Definition of Done?
Definition of Done (DoD) is an agreed list of activities that the team performs during an iteration for each item taken from the Product Backlog for development. DoD is a quality measure that every functionality developed by the team must meet. Features (user stories) that don’t meet the DoD at the end of the iteration are not presented to the client at the Iteration/Sprint Review meeting, as they are not considered complete (Done).
In environments where multiple teams work simultaneously on the same product, there must be a commonly agreed DoD, typically determined at the first backlog refinement meeting. Individual teams can set additional, stricter requirements for their DoD if they consider it beneficial.
Some examples of Definition of Done:
- Integration tests completed
- Regression tests completed
- User tests completed
- Refactoring completed
- Architecture compliance confirmed
- Acceptance criteria met
- New API versions presented to other teams in workshop
- Documentation updated
- All images compressed
Definition of Done vs. Acceptance Criteria
Acceptance Criteria (AC) are measures that confirm the developed functionality meets customer needs. Each user story has one or more acceptance criteria. They are determined by the client based on their business needs. As such, acceptance criteria are different for each user story.
AC can be descriptive or structured in a way that allows direct preparation of automatic tests in TDD (e.g., Gherkin syntax). In the most mature environments, the client even provides AC in the form of a test. In this case, tests replace AC. Regardless of the form, it is definitely recommended that meeting AC is part of DoD.
The image below shows an example of a Given-When-Then test scenario based on Gherkin syntax. I cover this topic in more detail in the context of product management during the Product Owner course.
On the other hand, DoD rarely changes during a single iteration (or iterations). As a quality measure, it is primarily determined by developers in collaboration with the Product Owner.
In general, we can say that DoD:
- Ensures consistent quality of product increments
- Reduces the need for rework
- Aligns understanding of quality criteria among stakeholders
- Enables more accurate progress measurement and consequently better planning
However….
Evolution of DoD
…. ….with the right approach, DoD can become a catalyst for Agile transformation.
Typically, Agile teams should deploy to production at least at the end of each iteration/sprint. Business value is only realized when functionality is deployed to production. As long as developed functionality waits for release, the resources invested in it are not returning value and this is by Lean definition waste.
Batch releases where multiple functionalities are pushed to production at once are risky from the perspective of end-user feedback. With multiple new functionalities released simultaneously, it’s difficult to prioritize urgent fixes (Helpdesk overload), hard to determine the source of errors, and more difficult to perform a roll-back if it becomes necessary (e.g., if system responsiveness falls below acceptable levels).
The task of a quality Definition of Done is to enable production release at least once per iteration. If functionality is “Done”, the release can happen even mid-iteration. Why wait for the official end of iteration? This kind of dynamism is enabled by the so-called ideal Definition of Done.
The goal of Agile organizations is to achieve the ideal DoD. They approach this by gradually expanding DoD to include activities that remove barriers to continuous release to production. Getting closer to the ideal DoD can take years for larger organizations, but it’s possible. Amazon, for example, deploys to production every few seconds.
Practical Example
Note:
Just a short branch descriptions.
- Main (or master) – the always-stable branch containing production-ready code.
- Development (or dev) – the integration branch where ongoing work is merged before release.
- Feature – a temporary branch for developing a specific feature or change.
There are minor differences between Trunk-Based-Development and Git Flow approach, but these variations don’t affect the message of this article.
1.)
The development team starts with a DoD that states a Product Backlog Item (PBI) is complete when the following conditions are met:
- All acceptance criteria are met
- Refactoring is completed
- Code is implemented and reviewed. This means the developer has tested the code locally, and another developer has performed a local code review.
- Unit tests are written together with functionality implementation (in the same cycle), unlike TDD where tests are written before code.
- Code is integrated into the development branch (not the main branch).
- Functionality has successfully passed manual testing in the integration/staging environment.
1.1.)
Issues the team noticed after a few weeks of development:
- The development branch merges with main only every 1 to 2 weeks (at the end of iteration). Therefore, integration issues accumulate and are discovered late.
- “Done” actually means “development complete”, not ready for production.
- Even if the main branch is unstable, it doesn’t stop the team’s work because they rarely use it for development or testing. Main branch stability is important only on paper, but since it has little direct impact on daily development, the team rarely focuses on it.
2.1.)
Based on the above observations, the development team supplements the DoD. A PBI is now considered complete when:
- All acceptance criteria are met
- Refactoring is completed
- New code is integrated into the main branch.
- All automatic tests (unit, integration, regression) in the Continuous Integration (CI) pipeline are successful.
- Code automatically integrates into the test/staging environment. This eliminates the bottleneck of waiting for manual inclusion of new code into the test environment (early signs of DevOps?).
- There are no open critical bugs. Statements like: Feature is done, just this bug remains. We’ll fix it another time ” are not acceptable.
2.2.)
The consequences of changing DoD are:
- Developers are forced to integrate into the main branch more frequently. The main branch thus becomes the “nerve center”, as everyone uses it as a basis for their work. If the main branch is unstable, it immediately stops everyone’s work (because testers can’t test, developers can’t confidently work on new tasks). Thus stability becomes operationally critical and affects team productivity in real time. Consequently, daily integration (or multiple times daily) becomes the norm. The system is similar to the Andon cord in Toyota Production System.
- Because manual execution of all regression tests with frequent integrations is impossible, the team is forced to establish an automated Continuous Integration (CI) pipeline that builds, tests, and deploys the application to the test environment with every change in the main branch.
- With continuous integration, integration conflicts and environment issues are greatly reduced.
- Cultural shift towards CI mindset. Since CI has become essentially a requirement for the enhanced DoD, this leads the team towards being “production ready” after each change.
Let’s say a developer completes the “User Profile Picture Upload” functionality.
Old DoD: functionality merges into dev branch, QA tests it in the next sprint, then merges into main branch weeks later.
New DoD: functionality needs to be integrated into the main branch today, which triggers:
- automatic build,
- static code analysis for detecting errors, standard deviations, and vulnerabilities (ESLint, Flake8…),
- unit tests,
- integration tests,
- regression tests,
- deployment to test/staging environment.
If such a pipeline fails, the functionality is not complete.
With such a comprehensive DoD, the team practically starts implementing Continuous Integration (CI) with every completed PBI, even if CI was never formally declared as a goal.
Why Don't Organizations Deploy to Production Continuously?
The first reason is of course: “Our situation is different/more complex/regulated/connected… ⇐ choose your favorite”. Here’s a list of the most common “reasons” and solutions:
From the table above, we can see that expanding DoD towards ensuring Continuous Integration/Continuous Deployment also requires senior management cooperation, as it often affects the organization’s overall operations.
At the beginning of development/project, DoD will likely be far from ideal. Reasons for this could be currently insufficient technical knowledge of developers, an insufficient number of developers to form real cross-functional teams, isolation of the Agile initiative from other parts of the organization, or unfamiliarity with the initiative’s challenges.
At the end of iterations, functionalities completed based on this incomplete DoD probably won’t be directly suitable for production. Unperformed (but release-important) activities could include unexecuted regression, performance and/or user tests, use of different API versions and different design patterns in related modules. This unfinished work is what separates teams from the ideal of Continuous Deployment.
Of course, the more iterations that pass without a release, the larger the inventory of unfinished work. This can create a false sense of progress. However, when management decides it’s time for release, it turns out that functionalities are far from ready for production and still require considerable work.
Organizations solve this predicament in various improvised ways:
- Hardening sprint/iteration is dedicated exclusively to optimizing code that should “somehow” already be ready for production, but obviously isn’t.
- Release sprint/iteration is dedicated to preparing developed code for production integration. Usually, this means that development didn’t test in a test environment that was a copy of production.
- Integration team, which continuously integrates code from other teams into a functional whole.*
- Undone team, which continuously takes over unfinished work and completes it, thus preparing it for release – dream job 🙁
All of the above are undesirable patterns.
* Some Scaled Agile frameworks (Nexus, SAFe) do include integration teams, but their primary task isn’t direct code integration, but rather helping teams with the integration process.
Such unplanned release delay can be a hard blow for an organization, as releases are often coordinated with parallel activities that need to be planned in advance. These include marketing campaigns, public product announcements, partner conferences, after-sales support training, and financial flows.
We probably agree that a comprehensive (ideal) DoD is beneficial for achieving Agile flexibility, work optimization, and faster ROI. What prevents organizations from expanding DoD?
A generic answer to this question would be that “barriers to DoD evolution need to be sought at all organizational levels. Especially by analyzing the interaction of individual system parts (systems thinking) …. bla, bla, bla”. In practice, however, each development team knows best what’s hindering them from achieving the goal of Continuous Integration/Continuous Deployment and the related ideal DoD.
When an organization identifies reasons for non-optimal DoD, their resolution is added to the organizational or product backlog (depending on whether they require strategic or operational changes). In the next cycle, changes are implemented and evaluated over the next few cycles. Successful changes are maintained or upgraded, unsuccessful ones are discarded.
DoD expansion is a key tool for interested leadership in implementing organizational changes. The key word in the previous sentence is “interested”. Agile transformation is beyond the scope of this article. Scaled Agile frameworks LeSS and Scrum@Scale deal extensively with this challenge. Each in its own way, but the common thread of both types of transformations is following good Agile practices and spreading this mentality to the rest of the organization. DoD expansion can be a useful tool in this process.
You’ll learn more about advanced Agile approaches in the Scaled Agile course.
The table below describes organizational maturity levels that also condition the maximum possible scope of Definition of Done.
Conclusion
Definition of Done is an essential tool for ensuring the quality of the developed product. At the same time, its enhancement towards Continuous Integration catalyzes necessary organizational changes. The result is an increasingly Agile organization that reaps more benefits from this approach.
