9.6.1.2 - How to Define “Done”: Checklists for Dev, Design and Support (Difficulty: Advanced | Path: Scale)

In the high-stakes environment of scaling a digital business, few things burn cash faster than the "Ping-Pong Effect." This occurs when a team member marks a task as "Complete," only for you or a quality assurance lead to open it and immediately find basic errors. Perhaps the mobile view is broken, a link leads nowhere, or a design file is missing its assets. You send it back. They fix it. You check again. They missed something else. This cycle destroys velocity, demoralizes teams, and creates an adversarial relationship between management and creators.

The root cause of this friction is rarely incompetence; it is almost always ambiguity. In the absence of a shared standard, "Done" is subjective. To a developer, "Done" might mean "I wrote the code." To a designer, it might mean "The mockup looks good in Figma." To you, the business owner, "Done" means "It is ready for the customer to use without embarrassing us." These definitions are often miles apart. Bridging this gap requires a strategic shift from implicit assumptions to explicit agreements.

The Definition of Done (DoD) is that bridge. It is not merely a to-do list for a specific task; it is a universal quality standard applied to all work produced by a specific role or department. It acts as a strict gateway: work cannot move from "In Progress" to "Review" (or "Deployed") until every single item on the DoD checklist is ticked. This shifts the responsibility of Quality Assurance (QA) leftward, placing it directly in the hands of the creator before they ever signal completion.