Definition of Done

The Definition of Done (DoD) is an essential concept in agile software development and defines a shared standard that determines when a unit of work can truly be considered "done." It serves as a quality checklist and creates a common understanding within the team and with stakeholders about the expected quality of delivered work.

Importance and Objectives

The Definition of Done fulfills several important functions in agile projects:

• Quality Assurance: Ensuring a uniform quality standard for all work results
• Transparency: Clear communication about what "done" actually means
• Planning Reliability: A dependable basis for sprint and release planning
• Risk Minimization: Reduction of technical debt through complete completion
• Shared Understanding: Aligning expectations within the team and with stakeholders
• Avoiding "Almost Done": Eliminating the common phenomenon of items being described as "95% complete"

Levels of the Definition of Done

The Definition of Done can be applied at various levels:

1. Story Level

Defines when a single user story is considered complete. Typical criteria include:

• Code was written according to coding standards
• Unit tests were implemented and passed
• Code review was conducted
• All acceptance criteria are met
• Functional tests were passed
• Documentation was updated

2. Feature Level

Defines when a larger feature or epic is considered complete. Additional criteria could include:

• Integration test scenarios were passed
• Non-functional requirements were validated
• Feature-specific documentation was created or updated
• UX review was conducted
• Performance tests were passed

3. Sprint Level (Increment)

Defines when the entire sprint increment is considered complete. Additional criteria could include:

• All stories in the sprint meet their individual DoD criteria
• Integration of all stories was tested
• Build is stable and functional
• Sprint demo was prepared
• Release notes were created

4. Release Level

Defines when a product is ready to release. Additional criteria could include:

• End-to-end tests were passed
• Security audits were conducted
• User documentation was updated
• Marketing materials were prepared
• Support team was trained
• Release plan and rollback strategy were defined

Elements of a Good Definition of Done

An effective Definition of Done should cover the following aspects:

1. Code Quality

• Adherence to coding standards and best practices
• No critical bugs or code smells
• Adequate code commenting
• Successful code reviews
• Adherence to architecture and design principles

2. Testing

• Unit tests written and passed
• Integration tests conducted
• Acceptance tests successful
• Manual tests completed
• Test coverage meets defined thresholds
• Regression tests conducted

3. Documentation

• Code documentation updated
• Technical documentation supplemented
• User documentation adjusted as needed
• API documentation updated
• Changes reflected in architecture or design documents

4. Deployment and DevOps

• CI/CD pipeline successfully completed
• Deployment scripts updated
• Configuration management conducted
• Database migration defined and tested
• Monitoring and alerting set up

5. Non-Functional Requirements

• Performance criteria met
• Security requirements implemented
• Scalability aspects considered
• Accessibility guidelines adhered to
• Internationalization and localization implemented

Development and Evolution of the Definition of Done

The Definition of Done is not a static document but should evolve alongside the team and the product:

• Initial Development: A first version is created at the start of a project or when introducing agile methods
• Continuous Refinement: Regular review and adjustment, often within sprint retrospectives
• Gradual Raising of Standards: As team and product maturity grows, quality requirements are typically increased
• Context-Specific Adjustments: Consideration of specific requirements for different product areas or development phases

The evolution of the Definition of Done often proceeds in stages:

1. Basic Quality Assurance: Focus on functional correctness and basic code quality
2. Technical Excellence: Raising standards for test coverage, refactoring, and technical documentation
3. Operational Maturity: Integration of DevOps practices, monitoring, and operational requirements
4. Business Optimization: Consideration of user acceptance, marketability, and business value metrics

Definition of Done vs. Acceptance Criteria

It is important to distinguish the Definition of Done from acceptance criteria:

Definition of Done	Acceptance Criteria
Universally applicable to all stories/features	Specific to a single story/feature
Focus on quality standards and processes	Focus on functional requirements
Defined and applied by the team	Defined by the Product Owner/stakeholders
Changes relatively infrequently	Newly defined for each story
Checks "Was it done correctly?"	Checks "Was the right thing done?"

For a user story, both all specific acceptance criteria and all points of the Definition of Done must be fulfilled for the story to be considered complete.

Definition of Done and Technical Debt

The Definition of Done plays a decisive role in preventing technical debt:

• Prevents postponing important quality aspects to "later"
• Makes it transparent when shortcuts are taken (or must be)
• Creates a basis for consistent quality over time
• Reduces the risk of hidden problems that can become expensive later

When deviations from the Definition of Done are necessary in exceptional cases:

• Document these explicitly and record them as technical debt
• Create and prioritize a remediation plan
• Create transparency about the deviation for all involved parties
• Track the frequency of such exceptions as a metric

Definition of Done in the Context of Different Roles

Development Team

• Primarily responsible for creation and adherence
• Uses the DoD as a daily quality guide
• Reviews work results against DoD criteria
• Proposes improvements based on experience

Scrum Master

• Supports creation and refinement
• Helps the team apply it consistently
• Removes obstacles that make adherence difficult
• Promotes discussions about quality improvements

Product Owner

• Ensures the DoD covers customer and business requirements
• Considers the DoD in product planning and prioritization
• Communicates quality standards to stakeholders
• Only accepts work that meets the DoD

Management and Stakeholders

• Understanding the DoD as a quality guarantee
• Supporting the provision of necessary resources
• Consideration in budget and time planning
• Using it as a transparency instrument

Best Practices for an Effective Definition of Done

During Creation

• Collaborative Development: Involvement of all team members and relevant stakeholders
• Realistic Standards: Balance between ambition and practical feasibility
• Clear Formulation: Unambiguous, verifiable criteria without room for interpretation
• Visual Representation: Well-visible presentation in the team workspace
• Formal Agreement: Explicit agreement from all team members

During Application

• Consistent Enforcement: No exceptions without explicit documentation
• Regular Reviews: Review after each sprint as part of the retrospective
• Automation: Where possible, verification through automated tests and CI/CD
• DoD Checklists: Integration into the workflow, e.g., in Jira or on Kanban boards
• Reflection: Regular discussion about whether the DoD meets current quality requirements

Challenges and Solutions

Challenge: Overly Ambitious Definition of Done

Solutions:

• Phased implementation with a base DoD and an expansion plan
• Prioritization of the most important quality aspects
• Regular review of practicability
• Investment in automation to increase efficiency

Challenge: Inconsistent Application

Solutions:

• Regular reminders and reflections
• Peer reviews with a DoD focus
• Visualization of the DoD status for each backlog item
• Definition of clear consequences for non-compliance

Challenge: Resistance to High Quality Standards

Solutions:

• Education about the long-term costs of technical debt
• Measurement and visualization of the positive effects of high quality
• Recognition and appreciation of quality contributions
• Gaining executive sponsorship for quality initiatives

Example of a Comprehensive Definition of Done

A complete Definition of Done could include the following elements:

Code Quality:

• Code complies with the agreed coding standards
• Code is documented in the development language
• Code review was conducted and all comments were addressed
• No critical issues in static code analysis
• Complexity metrics are below defined thresholds

Testing:

• Unit tests cover at least 80% of new/changed code
• All tests (unit, integration, E2E) run successfully
• Manual tests of the functionality were performed
• All acceptance criteria were verified
• Cross-browser/cross-device tests were performed for UI changes

Documentation:

• Architecture and design documentation was updated
• API documentation (where relevant) was created/updated
• Release notes were prepared
• Operational documentation was updated
• User documentation was adjusted as needed

DevOps and Deployment:

• Feature was tested in the staging environment
• CI/CD pipeline runs without errors
• Deployment and rollback instructions were updated
• Monitoring and alerting were configured
• Database changes are backward compatible

Non-Functional Requirements:

• Performance tests show no degradation
• Security guidelines were followed
• Accessibility requirements were considered
• Internationalization and localization were considered
• Data protection requirements were implemented

Business and Stakeholders:

• Product Owner has accepted the implementation
• Demo was conducted for relevant stakeholders
• Marketing materials were updated as needed
• Support team was informed/trained
• Business KPIs for success measurement were defined

The Definition of Done is a living document and a central component of agile quality assurance. It helps teams deliver consistent, high-quality work results and creates transparency and trust among all involved parties. By clearly defining "done," misunderstandings are avoided, technical debt is reduced, and long-term product quality is secured.