It is Friday afternoon. The end of the Sprint is approaching. Several stories are not finished and the pressure rises. A few tests could perhaps be skipped. A defect may not be serious enough to hold the story back. Regression testing could be completed later.
Nobody says, “Let’s accept more product risk so that we can avoid Sprint spillover.” Yet that may be exactly what is happening.
This made me look differently at the Definition of Done. Why are its criteria there in the first place? If testing, review, security checks or other quality controls are part of the DoD, they should not merely be activities the team has agreed to perform. They should be there because they control risks that matter.
Seen that way, there are two quite different problems with a Definition of Done.
The first is that it may not have been defined particularly well. It can become a generic checklist of things teams conventionally do rather than a set of controls related to the actual risks of the product.
The second is that even a meaningful DoD may become negotiable when delivery pressure rises.
“Can we skip this test so we can finish the Sprint?” sounds like a delivery question. But if the test exists to control a risk, the real question is closer to:
What risk was this test controlling, and are we prepared to accept the residual risk without it?
That may be a perfectly legitimate decision. The point is that it should be recognized as a risk decision. This suggests that risk should be made more explicit in the work itself.
A user story normally contains intent and acceptance criteria. It could also identify the significant quality risks associated with the story: what might prevent the intended outcome, how likely that is, and how serious the consequences would be.
Acceptance criteria and risk then serve related but different purposes. Acceptance criteria help us judge whether we implemented what we intended. Risk-based evidence helps us judge whether the important undesirable outcomes have been sufficiently controlled.
That leads to an interesting reinterpretation of Ready and Done.
The Definition of Ready becomes a shared checkpoint asking whether we understand the work — including its significant risks — sufficiently to start responsibly.
The Definition of Done becomes the corresponding checkpoint at the other end: have those significant risks been sufficiently mitigated, and do we have appropriate evidence to support that judgment?
In simple terms:
Ready: do we understand the important risks sufficiently to proceed?
Done: do we have sufficient evidence that those risks have been addressed to proceed further?
But then another problem appears: stories do not exist independently.
Story A can be Ready. Story B can be Ready. Story C can be Ready. Yet combining them in the same increment may create risks that none of the stories contains individually. They may change the same component. One may invalidate assumptions made by another. Performance, security, resilience or operational complexity may emerge only when the changes interact. So readiness has an increment aspect too.
It is not enough to ask whether the individual stories are Ready. We also need to ask whether we understand the significant risks created by combining them.
The same applies to Done. Three stories can individually satisfy their DoD while the integrated increment still behaves unacceptably.
A set of Done stories does not automatically make a Done increment.
As work aggregates, risk can emerge at the new level. Assurance therefore has to aggregate with it.
The same logic can continue toward release. A completed increment can still be unsuitable for deployment because release and operational risks only become meaningful at that level.
What started as a Scrum mechanism therefore begins to look more like a broader assurance chain:
Intent → Risk → Control → Evidence → Judgment
At each level, we are asking what we are trying to achieve, what could prevent it, what controls those risks, what evidence we have, and whether the remaining risk is acceptable.
And the chain should not end when the release reaches production. Production gives us new evidence. Some risks materialize despite our controls. Some turn out to have been underestimated. Others were never identified at all.
Eventually, the production defect may come back to the development team. But the more important question is:
Did the defect come back, or did the lesson come back?
If an incident reveals that a risk was missed, misunderstood or inadequately controlled, that knowledge should change future stories, risk assessments, controls, and perhaps even what Ready and Done mean.
The loop becomes something like:
Ready → Develop → Done → Integrate → Release → Operate → Learn → Ready…
The product continues, and so should our understanding of its quality.
The principle that seems to emerge is simple:
As work aggregates, assurance must aggregate with it.
That turns Ready and Done from static checklists into checkpoints in a continuous quality-learning system.
Leave a Reply