A team's Definition of Done is "that team's" statement that no more work is left to be done on that piece of functionality. Depending on the maturity of the team the definition of Done may be more narrow or more broad. There is no one "Standard" Definition of Done that can be applied to all projects and teams. The details of the Definition of Done will vary based on team as well as solution maturity and the type of work the team does.
The Acceptance Criteria for the User Stories, created by the Product Owner through customer meetings, will be the basis for the Definition of Done. Durring Sprint Planning the User Stories and Acceptance Criteria will be reviewed and refined. The refined Acceptance Criteria will then be presented to the customer for approval being added to the Project Backlock and scheduled into a Sprint for completion. In most cases, a new agile team will adopt a narrower definition of done. A new team may not have yet implemented enough automation to get to a broader definition in the short span of time allowed by a two-week sprint. On a new project the Definition of Done may be more narrow as well since the may not be enough of the solution completed to justify a deployment to QA. A narrow or Minimal Definition of Done might include simple things such as:
- Build completes successfully
- Automated Unit Tests complete successfully
- Automated Integration Tests complete successfully
- All Acceptance Criteria is met
A definition of done of this scope makes good sense for a team struggling just to stay on track with completing scrum ceremonies in a timely fashion.
As the team perfects the scrum ceremonies and their agile cadence takes hold it will then be time to expand the team's definition of done. A more expanded definition of done might include additional things like:
- Deployment to the QA environment completes successfully
- Automated acceptance tests passing
- Automated Load Tests completing successfully
- Automated Stress Tests completing successfully
Note: These items are completed in addition to the items in the Minimal Definition of Done.
As you can see getting to this broader definition of done might prove challenging if your team is still performing deployments and tests manually. In more arcane development days past the development team would celebrate and wash their hands of the project, exclaiming "Done! We're going to Tahoe", as soon as the coding was complete but long before any tests or security scans were run or the solution was successfully deployed to QA let alone production. It is this "Tahoe Effect" that we are looking to avoid with a broader Definition of done.
In short Defining "Done" and posting your definition in a highly visible place where the entire team has access will serve as a constant reminder of what Done really means. This well understood Definition of Done will go a long way toward building quality into your solutions earlier in the Delivery Pipeline and build confidence with downstream teams.