Everybody wants quality. Until quality gets in the way.
Imagine a development team approaching an important deadline. The functionality has been implemented, the documentation updated, and the tests executed. But some tests have failed. Others haven’t been executed. And there are still questions about whether the solution meets its quality expectations.
The deadline is tomorrow. Is the work done? That depends on the Definition of Done. And that’s where things become interesting.
The Convenience of Being Done
A Definition of Done (DoD) establishes the conditions under which work can be considered complete. In practice, many DoDs concentrate on activities: code reviewed, tests executed, documentation updated.
These are useful activities. But completing them doesn’t necessarily mean achieving their intended results. A review can be completed with significant findings unresolved. Tests can be executed without passing. Documentation can be updated without becoming accurate.
An activity-based DoD allows us to demonstrate that we’ve performed the expected work without necessarily demonstrating that we’ve achieved the expected quality. And that’s rather convenient when a deadline approaches.
Three Questions About Done
A meaningful Definition of Done should address three questions.
1. Criteria: What must be true for the work to be considered done?
We need to establish the quality expectations that apply to the result.
2. Evidence: How do we establish that those criteria have been satisfied?
Quality expectations aren’t enough. We need evidence supporting the conclusion that they’ve been met.
3. Consequences: What happens when they haven’t?
Suppose the evidence is insufficient, or demonstrates that the criteria haven’t been satisfied. Can we still declare the work done? Who decides? And what happens to the deadline?
The first question defines our expectations. The second makes them verifiable.
The third determines whether they actually matter.
Why Quality Is Inconvenient
Teams are expected to deliver. Project managers are expected to meet deadlines.
Quality work can interfere with those expectations. Testing reveals defects. Reviews uncover problems. Analysis demonstrates that a solution isn’t fit for its intended purpose. Of course, quality work can prevent expensive rework and improve delivery performance. But those benefits aren’t always immediate.
The cost of investigating a problem is visible today. The cost of failing to investigate it may emerge months later, perhaps in another team’s budget. A missed deadline is immediately visible. Insufficient quality may not be. This creates an incentive to prioritize what can be demonstrated now over what might matter later.
And teams adapt to the expectations placed upon them. When defining their DoD, they may gravitate towards conditions they can reliably satisfy without jeopardizing delivery commitments. Not because they don’t care about quality, but because they’re responding to the organization’s actual priorities.
The DoD becomes compatible with the incentives of the organization.
The Convenient Quality Gate
A DoD that says tests have been executed is easier to satisfy than one requiring specified tests to pass and unresolved failures to be evaluated. A DoD that says documentation has been updated is easier to satisfy than one requiring evidence that it’s accurate and sufficient for its intended users. The difference is that the second formulation may prevent the team from declaring the work done.
We can make a DoD appear rigorous by specifying activities while leaving the evidence of quality insufficiently defined. Whether consciously or unconsciously, this allows us to avoid the consequences of a genuine quality gate.
Other industries offer useful perspectives. In safety-critical aviation development, verification evidence is essential to demonstrating compliance. In medicine, surgical safety procedures establish checks that must be addressed before proceeding. Neither approach guarantees perfect outcomes. Nor should ordinary software development adopt their practices wholesale.
But they illustrate an important principle:
Quality obligations can be conditions for proceeding, rather than considerations to be abandoned when delivery becomes difficult.
What Happens When We Aren’t Done?
Suppose we’ve defined meaningful criteria and the evidence needed to demonstrate that they’ve been satisfied. Now the deadline arrives. The evidence is insufficient. What happens?
We might delay delivery, reduce scope, complete the necessary verification, or explicitly accept certain risks where that’s permissible. These can all be legitimate decisions. The important point is that someone must make one. We can no longer quietly transform incomplete assurance into completed work.
And that decision may be uncomfortable. It may affect commitments, budgets or schedules. Someone may have to accept responsibility for a risk they would rather not acknowledge. But that’s precisely why the Definition of Done matters.
A quality gate that cannot influence a delivery decision isn’t much of a gate.
The Real Test
We often discuss Definitions of Done as methodological instruments. We debate their contents and how teams should formulate them.
But perhaps the more important question is organizational:
Are we prepared to accept the consequences of defining Done properly?
If management rewards meeting deadlines while treating quality as negotiable, teams have little incentive to create a DoD that might prevent them from declaring success.
The vague DoD is where the problem becomes visible. The organizational incentives may be where it originates. And imposing stricter DoDs won’t necessarily help if those incentives remain unchanged.
A Definition of Done is most valuable when it tells us something we don’t want to hear. Everybody wants quality. Until quality gets in the way.
That’s when we discover whether our Definition of Done is a genuine quality gate—or merely a convenient way to declare that we’re finished.
The next time your team fails to meet its Definition of Done, ask yourself: what happens next?
If the answer is “We deliver anyway”, perhaps the Definition of Done isn’t where the improvement needs to start.
Improving quality isn’t always about introducing better practices. Sometimes it starts with understanding why the practices we already have aren’t allowed to work.
Leave a Reply