Skip to main content

Definition of Done

What is the definition of done (DoD)?​

The Definition of Done is an agreed-upon checklist that must be completed before a user story, epic, feature, release, theme or initiative can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.”

According to The Scrum Guide:

“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”

Why is the definition of done important for agile teams?​

When adopting agile ways of working, every process should add value to the organization. The definition of done follows and implements the core agile principles in product development.

Transparency​

Creating a clear understanding across the organization promotes transparency. It helps avoid unnecessary conflict and misunderstandings due to differences of opinion or perspectives.

Learning​

Continuous evaluation at each step following the DoD checklist enables thorough oversight before releasing a product to end users and acts as a security gate. It allows the team to focus on speed and delivery, encouraging self-driven innovation without hesitation.

Iteration​

Delivering features that can be implemented quickly with the appropriate levels of quality assurance and delivered to end users is another key agile principle. Quick learning and iteration also foster confidence within the product development teams to create innovation while maintaining quality assurance during delivery.

DoD Levels​

  • User Stories
  • Epics or Features
  • Themes or initiative

User Stories​

The first and most basic level of DoD is a user story. A user story can be considered to be done when all mandatory checks have been passed. It should be noted that some parts of the checklist are optional depending on the project type. Once accepted, the completed user story contributes to the team velocity.

User Story DoD Examples:

  • Code committed to source control
  • Code peer reviewed
  • Code quality and standards met
  • Code builds and deploys to feature or test environment
  • Tests written and passed (unit/integration/visual)
  • Acceptance criteria met
  • Functional tests passed
  • Non-functional requirements met
  • Tested on devices/browsers
  • Meets UX criteria
  • Passes QA
  • Documentation created or updated
  • Analytics or tracking definition met*
  • End user training*
  • Demo*
  • Microservices Production Readiness Level*
  • UI and Content Production Readiness Level*

Epic / Feature​

At the feature or epic level, done means ready and shipped to the end user. An epic that is done has met all the criteria and fulfilled the user’s needs.

One or multiple user stories can conclude a feature in more than one sprint involving several cross-functional teams.

Here’s an example of DoD checklist for a feature/epic:

  • Demoed to and accepted by stakeholders
  • UX design reviewed and accepted
  • Integration and end-to-end test passed
  • Compliance requirements met
  • Automated regression test created
  • Defined user needs met
  • Feature documentation done
  • Signed-off by the agile team / squad. Engineer(s), Architect(s), Project Manager, Product Owner, QA, etc.
  • Promoted to the production environment

A shared understanding of the DoD on this level is essential if the quality of delivery to the end user is paramount. Furthermore, because multiple teams can be involved in the delivery and the development cycle may be longer, a well-defined and agreed-upon definition of done can help save time, increase efficiency, and ensure the quality and integrity of development before being released to production.

Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity.

Themes / Initiative​

Having a DoD for a theme or initiative is a relatively new concept that emerged in response to the popularity of product lifecycle management.

The DoD at the theme level helps the organization to align during prioritization, clarifies if there is any need to shift the focus on a new initiative, and pulls the plug on any further development on an existing product. DoD aids with strategic focus and direction for the entire product organization.

The example of the checklist in DoD for themes/initiatives can include:

  • Meets customer needs
  • Target architecture design is accomplished.
  • All MVPs are released to production and evaluated.
  • User tests and surveys were done and assessed.
  • No new requirements were identified.

Technical DoD​

We have also included a generic technical definition of done which can apply across most disciplines of code delivery. It is slightly more in depth and can be added to user stories and or epics and releases.

Stability​

  • Unit tests
  • Threshold test coverage - 60%
  • Recommended test coverage - 80%
  • Config in env-var

Reliability​

  • Automated builds
  • Automated deployments
  • Dependency analysis

Scalability​

  • Graceful degradation of UI

Fault Tolerance and Catastrophe-Preparedness​

  • Load testing
  • Stress testing
  • Performance testing and benchmarking (Application)
    • Render Times
    • Core Web Vitals
    • Lighthouse Scores
    • Content Sizes
    • Page Load Times
    • CPU Time
    • Critical Blocking Requests
    • Application size
  • Performance testing and benchmarking (Page)
    • Tracking
    • Accessibility
    • UX Testing
    • SEO Analysis
  • Mobile friendliness

Monitoring​

  • Application monitoring
  • Error logging
  • Health checks

Documentation​

  • README
  • Architectural designs
  • Flow diagrams
  • JS/TSDoc
  • End User Training

Resources​