- Related reading: Maturation (Simplification) of Definition of Ready (DoR)
- Definition of Done (DoD) Example
By design, feature teams tend to be more mature then component teams, with respect to DoD, and this could increase (not guarantee) their chances of delivering PSPI at the end of the sprint. However, in complex organizational settings, even feature teams could have “UnDone” left-overs by sprint-end, because some activities (e.g. end-to-end testing, production deployment) are still handled by other teams due to organizational boundaries.
Even if a team’s an initial DoD is weak, it should a team’s goal to gradually (from sprint to sprint) expand DoD, while shrinking (reducing) UnDone work. Undone work may never reach a zero mark, but making it smaller and smaller, should be every team’s aspiration. Btw, maturity of DoD is probably one of the most useful and reliable maturity metrics that a team may use (by far, more useful that majority of vanity metrics that organizations impose upon teams).
It is important to recognize that for many organizations, difficulties with expanding DoD are caused by internal politics and contractual relationships (when different teams, departments, managers compete for control and power).
Let’s further explore how a team may gradually expand its DoD, by gradually expanding its DoD.
While making a journey, from being a single component team to a feature team, a team gradually becomes proficient and capable of more advanced work: from coding a single component, ➡ to designing and unit testing, ➡ to architecting and testing a subsystem, ➡ to analysis and whole system testing, … all the way to co-creation.
As per Feature Team Adoption Map (FTAM) below, while advancing in the functional dimension (X – axis), a team becomes more capable to expand its scope of work in technology dimension (Y-axis): from a single component, to sub-system, to whole product, to whole system, to problem solving and beyond – essentially, expanding it’s DoD.
As mentioned, a component team that can code only one component, will have a lower-maturity DoD and extensive UnDone work. On contrary, a feature team can perform multiple activities (e.g. code in multiple components, design/architect, text, co-create) and work on the whole product, will have a higher-maturity DoD and less extensive UnDone work.
Many organizations have difficulty defining real products from a business/customer perspective, and here are some reasons for this:
Traditionally, this initiative has been driven by technology, because a typical agile transformation has also been driven by IT. As such, products have been frequently organized around architecture, components and technology language, instead of customer-centric requirements and customer language.
Even if/when business has been involved in product definition activities, people that are best suited for the job (e.g. head of business operations, customer-facing senior product manager, power users) would not available, e.g. for the role of Product Owner. Instead, this responsibility would be delegated to business analysts, business-side project managers, program managers, portfolio managers, and other roles that come from traditional organizational structures, where customer centricity and product focus historically had not been a priority.
As a result of the above, and because traditional business-to-technology “alignment” has been treated more as a “PR” (a nice thing to claim), rather then as a genuine bi-lateral effort, the following trend is usually observed: work done by component/shared services/platform/architecture teams gets “re-packaged” into projects, programs and portfolios, now called “tech-for-tech” products, sub-products, products families, product lines, a.k.a. FAKE PRODUCTS – to be further managed, as it is usually done, by any traditional organization. Essentially, this makes a product definition into becoming the hostage of traditional organizational structure.
Larman’s Law #5 states: “culture follows structure“, alluding to the fact that in complex organizational settings, we should expect a cultural environment be a reflection of organizational structure. By the same token, in product-centric/customer-focused organizations, organizational structure should follow product definition that an organization creates for customers, NOT the other way around: product definition should NOT follow a blueprint of traditional organizational design.
Example Of Definition of Done (DoD):
1. Functional Completeness
- Acceptance criteria are fully met.
- Product Owner accepts the functionality.
- User value has been delivered.
- No known functional gaps remain.
- Feature behaves as expected.
2. Quality
- Code meets agreed quality standards.
- Peer review has been completed.
- No critical or high-severity defects remain.
- Technical debt introduced is acceptable and intentional.
3. Testing
- Unit tests are written and passing.
- Integration tests pass.
- Functional tests pass.
- Regression tests pass (manual or automated).
- Acceptance tests pass.
- Test coverage meets team expectations.
4. Integration
- Changes are integrated into the main branch.
- Build completes successfully.
- No merge conflicts remain.
- Product increment integrates with existing functionality.
- No broken dependencies exist.
5. Deployment Readiness
- Product is deployable.
- Deployment has been validated.
- Configuration changes are complete.
- Feature toggles are configured (if used).
- Rollback approach exists (where appropriate).
6. Non-functional Quality
- Performance expectations are met.
- Security requirements are satisfied.
- Accessibility requirements are met.
- Reliability requirements are satisfied.
- Compliance requirements are fulfilled (where applicable).
7. Documentation
- User-facing documentation is updated (if needed).
- Operational documentation is updated (if needed).
- Release notes are prepared (if applicable).
- API documentation is updated (where relevant).
8. Operational Readiness
- Monitoring is configured.
- Logging is implemented.
- Alerts are updated (if required).
- Support teams have necessary information.
- Operational impacts are understood.
9. Product Completeness
- Increment is usable.
- Increment could be released today.
- No outstanding work is required to realize customer value.
- Increment contributes toward the Product Goal.
- Product remains in a releasable state.
10. Team Accountability
- Team collectively agrees work is Done.
- No hidden work remains.
- Remaining defects are transparent and intentionally accepted.
- Team is confident in the quality of the Increment.
Common Definition of Done Anti-Patterns
These often indicate organizational dysfunctions or misuse of the Definition of Done rather than improving product quality:
- “Done” means only coding is complete.
- Testing is performed after the Sprint.
- QA is a separate phase after development.
- Product Owner acceptance occurs weeks later.
- Security review happens after release.
- Performance testing is deferred.
- Documentation is postponed indefinitely.
- Integration occurs after Sprint completion.
- Release requires another stabilization Sprint.
- Dedicated hardening or integration Sprints are required.
- Production defects are accepted as “normal.”
- Technical debt is routinely deferred without visibility.
- Features are considered Done despite known critical defects.
- Multiple Definitions of Done exist for teams working on the same product.
- Manual approvals determine Done rather than objective quality criteria.
- “95% Done” or similar partial-completion states exist.
- Done depends on another department completing work.
- Work is considered Done even though it cannot be deployed.
- Release readiness depends on large end-of-project testing or integration efforts.
- The Definition of Done changes from Sprint to Sprint to accommodate unfinished work.