6 August, 2026

Definition of Done: Stop Letting Projects Drag On Forever


What does ‘Done’ really mean in project management โ€” and why do so many teams get it wrong?

Is your team constantly delivering work that isn’t quite finished? This quick guide gives you the real meaning of ‘Done’ and how to create a robust ‘Definition of Done’.

We expose the hidden trap of ‘Done Drift’ that quietly destroys project quality over time. And I show you what to look for and how to combat it.

This video is safe for viewing in the workplace.

This is learning, so, sit back and enjoy

Done

The term โ€˜Doneโ€™ is pretty simple. But, in the context of Agile and software development, it has substantial importance. If you don’t have a clear definition of โ€˜Doneโ€™, you risk never achieving true completion.

The Concept of โ€˜Doneโ€™

In the simplest sense, โ€˜Doneโ€™ means that a piece of work (like a user story, a bug fix, or a task) has been completed and is ready for the next stage. This could be user review or deployment.

In addition, it must be completed according to the acceptance criteria, so โ€˜Doneโ€™ is not a feeling; it is a verifiable state.

The Definition of Done (DoD)

The Definition of Done (DoD) is a formal, explicit, and documented checklist that the entire team agrees upon and commits to. It is a quality standard for every increment of work.

If a piece of work does not meet every single item on the Definition of Done, it is not truly complete. It is not โ€˜Doneโ€™.

Without a Definition of Done: โ€˜Doneโ€™ often means:

  • “I finished coding it” or
  • “It works on my local machine.”

This is dangerous because it leaves crucial steps undone. It may work, but maybe:

  • It hasn’t been tested by QA
  • There are performance bottlenecks
  • Documentation is not finished

Key Characteristics of a Good DoD:

  1. It must have clear functional acceptance criteria and quality requirements that are testable. And it cannot be expressed in general, ambiguous, or subjective terms.
  • It must be shared by the whole team. IAnd it cannot be solely owned by the developer who wrote the code. Testers, BAs, DevOps, and the Product Owner all contribute to it.
  • It must be agreed before the work starts. You cannot retroactively decide what โ€˜Doneโ€™ means after the work is done.

What is Done Drift?

โ€˜Done Driftโ€™ is the natural enemy of healthy product development.

Done Drift is the process degradation that occurs when teams start to let Definition of Done standards slip and weaken, or they start to ignore it, under pressure.

The client, the team, or parts of the team begin to accept a lower standard of quality for what constitutes โ€˜Doneโ€™, leading to compromises in quality, technical debt, and rework, without officially changing the scope or the requirements.

It is the slow, corrosive tendency to say,

“That will do: it’s mostly done,”

How Does Done Drift Manifest? (The Symptoms)

Done Drift isn’t usually a sudden catastrophic failure. Rather, it’s usually a series of small compromises that add up:

  1. Skipping Testing:
    “We’re tight on time, so we’ll skip the full integration testing and just test locally.”
    (This sacrifices quality for speed.)
  2. Incomplete Documentation:
    โ€œThe user manual can wait until after the release, we shipped the code.”
    (This defers necessary future work.)
  3. Rushing Deployment:
    Pushing code to production before it has been through all necessary staging environments because
    “The deadline is immovable.”
    (This introduces unknown risks.)
  4. Technical Debt Accumulation:
    Accepting quick-and-dirty fixes (“hacks”) rather than implementing the proper, scalable solution because
    “It will take too long right now.”
    (This guarantees future slowdowns.)
  5. Shrinking the DoD:
    The team collectively decides,
    “We don’t usually do performance testing anyway; it’s optional.”
    (This degrades the baseline quality standard.)

In short, Done Drift leads to bugs, technical debt, rework,  and user or customer dissatisfaction.

How to Combat Done Drift (Preventing the Decay)

Since Done Drift is a gradual process failure, combating it requires continuous vigilance, not just a one-time agreement.

  1. Make the DoD Visible and Discussed:
    Don’t just write the DoD and forget it. Review it at the start of every Sprint Planning session. Ask:
    “Does this story successfully meet all aspects of our DoD?”
  2. Protect the Boundary:
    When scope creep or schedule pressure arrives, the team must protect the DoD. If the pressure is to ship on time, the realistic answer is:
    “We can ship without that feature.
    If we are going to ship that feature, we must follow the DoD, which requires this amount of extra time.”
  3. Measure the Drift (The Feedback Loop):
    When bugs related to integration or undiscovered issues arise in later stages (e.g., QA finds bugs that should have been caught by the original developer), stop and analyze. Ask:
    “Why was this missed? Did our DoD capture this failure point?”
    If the DoD didn’t prevent it, update the DoD.
  4. Celebrate Meeting the Standard:
    When the team delivers a truly โ€˜Doneโ€™ increment, one that has fully met the Definition of Done, acknowledge that success. This reinforces the value of following the quality process.

Summing up Done

By being hyper-aware of the difference between the ideal state (DoD) and the decaying reality (Done Drift), teams can maintain a sustainable pace of high-quality delivery.

Carefully curated video recommendations for you, to answer the questions, what is or are…


What Kit does a Project Manager Need?

I asked Project Managers in a couple of forums what material things you need to have, to do your job as a Project Manager. They responded magnificently. I compiled their answers into a Kit list. Then, I added my own. 

Check out the Kit a Project Manager needs

Note that the links are affiliated.

Learn Still More

For more great Project Management videos, please subscribe to the OnlinePMCourses YouTube channel.

If you want basic Management Courses – free training hosted on YouTube, with 2 new management lessons a week, check out our sister channel, Management Courses.

For more of our Project Management videos in themed collections, join our Free Academy of Project Management.

For more of our videos in themed collections, join our Free Academy of Project Management

Mike Clayton

About the Author...

Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Never miss an article or video!

 Get notified of every new article or video we publish, when we publish it.

>