"Done" vs. "Definition of Done": What's the Difference?

Understanding the Difference Between “Done” and “Definition of Done"

Recently, while discussing a particular project’s overruns with one of our Developers, he asked if utilization of a Definition of Done (DoD) list would help in ensuring the Project was complete. He seemed to think that DoD applied to the end of a Project as opposed to an ongoing checklist that is used throughout the Project.

To help make this clearer I’d like to explain to you how Definition of Done should be applied to help ensure a Project’s success, and how this differs from Acceptance Criteria and Project Close.

Firstly, What is DoD?

Often, the Definition of Done is confused with Acceptance Criteria (AC). They are not the same. AC is specific to individual user stories or features, while Definition of Done is typically in the form of a checklist that is applicable across all work items throughout the project. It is a repeatable set of processes and checks that are designed to ensure quality is maintained.

Key Purposes of the DoD

1. Quality Assurance: Ensures that work meets the agreed standards and minimizes technical debt.
2. Transparency: Provides a clear understanding of what "done" means for all team members and stakeholders.
3. Consistency: Helps create a uniform standard for completion across all features and user stories.
4. Inspection and Adaptation: Allows the team to regularly review and update standards to improve the process over time.

While AC is specific to a particular user story, it can certainly be included as one of the necessary criteria before a Story or Task can be confirmed as “Done”. Other criteria that may be considered include code reviews, completed documentation, and satisfactory deployment. It’s important that you define what is required for the success of your project.

An Example of a DoD Checklist

For a feature to be considered done, it might have to meet the following:

1. Code is written and reviewed: The feature has been fully developed, peer-reviewed, and adheres to coding standards.
2. Unit tests are written and passed: Automated unit tests are created for the feature, ensuring that the code works as expected in isolation, and all tests pass.
3. Integration and system tests are complete: The feature has been tested within the larger system, and no major bugs or issues are present.
4. Documentation is updated: All necessary documentation, including user manuals, technical documentation, or code comments, has been written or updated to reflect the changes.
5. Product Owner approval: The feature has been demonstrated to the Product Owner, who has reviewed and accepted the completed work.
6. Deployed to staging environment: The feature has been deployed to a staging environment for further testing or stakeholder review.
7. Meets performance standards: The feature adheres to predefined performance benchmarks, such as load time, response time, or memory usage.
8. User interface is polished: Any UI elements have been reviewed and are consistent with design guidelines and visual standards.
9. No critical bugs are open: All critical or high-priority bugs related to the feature have been resolved or mitigated.
10. Security checks are passed: Security vulnerabilities have been assessed and no high-risk issues are present in the feature.

💡Key Tip: When preparing your DoD to be utilized throughout your project, avoid anything that cannot be easily defined. Criteria such as “The site must look good” is far too subjective to be of any value in a DoD checklist. Criteria must be measurable and definitive.

If it’s “Done”—Can We Close the Project?

Unlikely. Confirming something is “Done” only applies to that specific story or task - Not the entire project. Essentially, throughout the course of a project there would be numerous DoDs, but only one Project Close, conducted at the completion of the Project.

Project Close

Project Close is the final step of the project lifecycle, where the entire project is wrapped up, and all final activities are completed. Unlike the DoD, Project Close signifies the end of the entire project.

• Purpose: To formally end the project, ensuring all deliverables are accepted, stakeholders are satisfied, and all administrative and financial processes are complete.
• Scope: Applies to the project as a whole.
• Key Elements:
  • Finalizing and delivering all project deliverables
  • Gaining client or stakeholder approval for the entire project
  • Conducting a lessons-learned review
  • Final financial reconciliation and closing of accounts
  • Archiving project documents and closing contracts
  • Formally releasing project resources and completing evaluations
• Example: After all software features are developed and accepted, Project Close would involve handing over the software to the client, completing financial reconciliation, documenting lessons learned, and closing the project.
• When Used: Only once, at the end of the project, to officially close it.

Summary of Differences

The DoD helps teams align on quality and completion standards during the project, while Project Close ensures the whole project is formally wrapped up and handed over.

Almost Done…

As a Project Manager, you may not be using DoD in your projects. However, while you may not have a clear, documented DoD checklist, I guarantee that you are applying at least some of the DoD principles. You may be applying some of these at every sprint completion, or prior to every deployment. Either way, these standard, repeatable processes are often the very same functions that you would include in your DoD.

If you are using DoD already, well done. If not, start now: Document your current processes, include the checks mentioned above and circulate them to everyone in your project - It provides clarity, sets definitive expectations, and goes a long way towards ensuring continued success throughout the project.

Done.