8.1 The Quality Practice in an Agile Context

8.1 The Quality Practice in an Agile Context

Quick summary: The quality practice exists to ensure that the users' requirements and expectations for the project's products are met. Its distinctive agile feature is that requirements are expressed in the project backlog, and that quality is built in continuously rather than inspected in at the end.

Purpose

The purpose of the quality practice is to ensure that the project's products meet the users' requirements and expectations, and are fit for purpose.

The phrase fit for purpose is doing real work. Quality in PRINCE2 is not "as good as possible" — it is "good enough for the use it will be put to, as agreed with the users". Gold-plating is a quality failure just as much as under-delivery is, because it consumes budget that the business case allocated elsewhere.

The PRINCE2 Agile approach: requirements in the project backlog

The characteristic statement of the quality practice in PRINCE2 Agile is that requirements are expressed in the project backlog.

This replaces the plan-driven pattern of a separate, signed-off requirements specification produced up front. Instead:

• Requirements live in the project backlog as prioritized items, refined into user stories as they approach delivery.
• Each item carries acceptance criteria — the specific, testable conditions for that item.
• All items must additionally satisfy the Definition of Done, the standard that applies to everything.
• The backlog is ordered by value, so the most important quality expectations are addressed first.

The benefit is that requirements stay current. A specification signed off in month one is a snapshot of what was understood in month one; a backlog is refined continuously as evidence arrives from real releases.

Be careful not to confuse this with the neighbouring practices. Benefits management actions and reviews should be defined belongs to the business case practice. Informal issues and required actions should be recorded belongs to the issues practice. Agile adoption issues are identified using the Agilometer belongs to the risk practice.

Quality is protected, not flexed

Of the seven performance targets, quality is one of those held firm in agile delivery, alongside time and cost. Scope is the variable that flexes.

The logic is straightforward. If a timebox is under pressure and quality is allowed to give, the team ships something that looks finished and returns weeks later as defects — which costs more than the scope that was protected. Worse, the degradation is invisible at the moment it happens, so governance cannot see it.

The mechanism that makes protection real is the Definition of Done. Because it is published, applies to every item, and is not variable by iteration, "we will drop a story" becomes the available response and "we will skip the regression tests" does not.

A nuance worth holding: PRINCE2 distinguishes quality criteria, which are fixed, from the quality tolerance attached to them. A criterion may legitimately carry a range — a page must load in under two seconds, with a tolerance to three — and that tolerance is agreed in advance rather than improvised under deadline pressure.

Who sets quality expectations

Quality expectations come from the users, not from the delivery team's professional judgement alone.

Note that testers are a named delivery role in the Version 2 syllabus. Testing is part of the team's work within the iteration, not a downstream department the work is handed to.

Building quality in

The practical differences from a plan-driven approach:

• Testing happens within the iteration, alongside development, so defects are found within hours rather than months.
• Automated regression testing makes the Definition of Done affordable to enforce every iteration.
• The product owner accepts or rejects each item against its acceptance criteria at the point it is completed.
• Reviews inspect working product, so users see the real thing early and quality expectations are corrected while correction is cheap.
• Technical debt is tracked, because the eventual consequence of poor design or poor development is debt that slows all future delivery.

Tailoring the quality practice

• Regulated environments constrain how far quality documentation can be right-sized. Evidence that must be retained must still be produced — but it can be generated by the pipeline rather than written by hand.
• The quality management approach is still agreed at initiation; what changes is that much of it is discharged through the Definition of Done and automated checks rather than through scheduled quality reviews.
• The Definition of Done is agreed with, and visible to, the project board, because it is the guarantee underlying the fixed-quality target.