8.2 Quality Artifacts and Techniques: Ready, Done and Continuous Testing
Key Takeaways
- The quality management approach, product descriptions and the quality register are the practice's PRINCE2 artifacts; the Definition of Ready and Definition of Done are its agile ones.
- The Definition of Ready is the entry gate into an iteration; the Definition of Done is the exit gate applying to every increment.
- Acceptance criteria are specific to an individual item, whereas the Definition of Done applies to all work.
- Behaviour-driven development expresses acceptance criteria as concrete examples that can be automated as tests.
- Technical debt is the eventual consequence of poor system design or poor software development, and a weak Definition of Done is how it accumulates.
8.2 Quality Artifacts and Techniques: Ready, Done and Continuous Testing
Quick summary: PRINCE2 artifacts — the quality management approach, product descriptions, the quality register — combine with agile ones: the Definition of Ready, the Definition of Done, acceptance criteria, behaviour-driven development and continuous integration. Together they make "quality is fixed, scope flexes" enforceable rather than aspirational.
Artifacts
| Artifact | What it holds |
|---|---|
| Quality management approach | How quality will be managed on this project: standards, responsibilities, tools, and how the Definition of Done relates to formal quality control |
| Project product description | The overall product: its purpose, composition, the customer's quality expectations and the acceptance criteria for the project as a whole |
| Product description | An individual product: purpose, composition, quality criteria, quality method and quality responsibilities |
| Quality register | The record of planned and completed quality activities and their results — the audit trail that the approach was actually followed |
| Definition of Ready | Conditions a backlog item must satisfy before a team commits to it |
| Definition of Done | Conditions every increment must satisfy before it is complete |
| Acceptance criteria | Item-specific, testable conditions for a single story or product |
Tailoring point: on many agile projects the product description for a small item is effectively carried by the user story plus its acceptance criteria. This is legitimate right-sizing — the information is still there, in a lighter form. What would not be legitimate is having no agreed quality criteria at all.
Definition of Ready — the entry gate
The Definition of Ready states what must be true before a team will pull an item into an iteration. Typically the item must be:
- Small enough to complete within one iteration
- Written with clear, testable acceptance criteria
- Understood by the whole team, with dependencies identified and unblocked
- Estimated by the team
Its purpose is to prevent the commonest cause of a failed iteration: committing to work that turns out to be underspecified, and finding out on day four.
Definition of Done — the exit gate
The Definition of Done states what must be true before an increment is complete. It applies to every item, and it is the single most important quality artifact in an agile project because it is what makes the fixed-quality target enforceable.
A representative Definition of Done:
- Code written, peer reviewed and merged
- Unit and integration tests written and passing
- Automated regression suite passing
- Security, accessibility and regulatory checks passed
- Documentation updated to the agreed level
- Deployed to a test environment and demonstrated
- Accepted by the product owner against the acceptance criteria
Three properties matter:
- It is agreed in advance, not negotiated when the deadline bites.
- It is visible, including to the project board, because it is the guarantee that underlies fixed quality.
- It is uniform. A Definition of Done that varies by iteration is not a standard.
Ready, Done and acceptance criteria compared
| Definition of Ready | Acceptance criteria | Definition of Done | |
|---|---|---|---|
| Scope | All items entering an iteration | One specific item | All completed increments |
| Gate | Entry | Item-level acceptance | Exit |
| Set by | The team, with the product owner | Product owner, from user needs | The team, agreed with governance |
| Varies per item? | No | Yes | No |
The trap: acceptance criteria and the Definition of Done are both required. An item that meets its acceptance criteria but not the Definition of Done is not done — it works, but it is untested, unreviewed or undocumented.
Techniques
Behaviour-driven development
Behaviour-driven development (BDD) expresses acceptance criteria as concrete examples of behaviour, conventionally in a Given / When / Then structure:
Given a customer with an overdue invoice, When they attempt to place a new order, Then the order is held for credit review.
The value is twofold. The example is precise enough to be automated as a test, and it is readable enough that a business stakeholder can confirm it is right. It closes the gap between what the user meant and what the developer built — which is where most defects originate.
Continuous integration and automated testing
Integrating work frequently and running an automated test suite on every change is what makes a demanding Definition of Done affordable. Without automation, a full regression check every iteration is too slow to perform, so it gets skipped — and the quality target quietly becomes flexible.
Continuous review and early acceptance
The product owner accepts or rejects each item as it completes, rather than at the end of a release. Feedback arrives while the context is fresh and the change is cheap.
Managing technical debt
Technical debt is the eventual consequence of poor system design or poor software development: accumulated shortcuts that must be repaid, with interest, as slower future delivery.
It is created by exactly the behaviour the Definition of Done is designed to prevent — shipping work that is not really finished. Managing it means making it visible (tracked as backlog items rather than tacit knowledge), budgeted (a share of each iteration's capacity allocated to reducing it), and understood by governance, because unmanaged debt eventually shows up as falling velocity and rising defect rates that no amount of pressure will fix.
An item satisfies all of its acceptance criteria but has not been peer reviewed or added to the regression suite. What is its status?
What is the eventual consequence of poor system design or poor software development?
What is the principal benefit of expressing acceptance criteria using behaviour-driven development?