PRINCE2 Agile 2016
Previous Section   Next Section

11.3 PRINCE2 Agile guidance for the Quality theme

11.3.1 How to use the PRINCE2 product description

Although product descriptions are mandatory in PRINCE2, they are very flexible and can be written in the form of epics or user stories as long as they meet the requirements of the product description outline (as defined in Appendix A). These represent what are commonly referred to as the project’s ‘requirements’ (see Figure 25.1 for an example of decomposition).

Product descriptions can be formal or informal, and they can evolve during the project to allow for change as long as it is clear what the baseline is and what level of plan they have been baselined to (e.g. they could be baselined at the stage plan level). The project management team may decide that the higher-level product descriptions need to be more formally defined (e.g. they are to be baselined in a configuration management system) and the lower-level product descriptions can be informal (e.g. captured as user stories on index cards).

When using agile with PRINCE2, full advantage should be taken of the flexibility built into the product description outline as shown in Table 11.1.

Product description component Guidance

Quality criteria

This usually equates to acceptance criteria (e.g. for a user story), although sometimes the definition of ‘done’ in Scrum is used for the same purpose. It should avoid too much unnecessary detail that will restrict positive change but does need to be of sufficient clarity so that it can be quality checked.

Quality tolerances

Use a range of values (perhaps prioritized) to allow for change.

Quality method

Select the appropriate technique for the agile environment – sometimes some form of automated ‘test-driven’ approach may be desirable/required (e.g. when writing software) whereas at other times a more conventional quality review may be the more appropriate (e.g. when producing a brochure).

Using the quality method to define the approach to quality would be specific to a particular product. A more general view across all products would be contained in the quality management strategy.

Table 11.1 How to use some of the product description components to provide flexibility

11.3.2 Creating the project product description

This can be crafted in a similar way to the product description in that the customer’s quality expectations, acceptance criteria and project-level quality tolerances are defined with a level of formality and detail that embraces the agile way of working.

Furthermore, when using agile the preferred way to define the purpose of the project product description is to use a clearly defined outcome (or outcomes) – see section 9.4.2 for more information on outcomes. This can also help if the contractual side of the project is to be based on a more agile style of working (see Chapter 28).

11.3.3 Quality management and quality planning

The tools and approaches that are to be used should be defined as part of the quality management strategy: working in an agile way needs the appropriate choice of tooling and techniques as teams may be distributed and the testing may be ‘test-driven’ (see section 11.3.4).

Definition: Test-driven

The concept of writing tests or quality checks before building the product or sub-product as opposed to after.

The role of the customer should be well defined as the customer is an essential ingredient when working in an agile way. Apart from their continual involvement and commitment, their responsibilities should be understood by all with respect to such things as:

  • customer acceptance
  • customer documentation
  • canvassing a wider customer view
  • attendance at product demos.

It is the upfront quality planning that enables PRINCE2 to develop a strategy for how testing and quality checking will be carried out prior to the work taking place. If several frequent releases are planned, then the resources needed (human or otherwise) can be assessed and costed so that they can be factored in to the business case.

Quality control considerations that look at what quality methods to use (e.g. the frequent use of demos and sprint reviews) are a natural evolution from this planning.

Ultimately the learnings from many projects contribute to the evolution of the wider quality management system for an organization, and part of this will involve development of the use of agile.

PRINCE2 takes a holistic view of the whole area of quality, which exists throughout a project and operates at all levels.

11.3.4 How to test: test-first, test-driven and test-as-you go concepts

When using PRINCE2 with agile, a decision has to be made early on, as part of the quality management strategy, as to how much of the testing and quality checking can be carried out in the preferred agile manner of ‘test/check first’ or at least ‘test/check as you go’. This is the one area where transferring agile concepts and techniques from the software development domain needs to be handled carefully. Software can be built iteratively and tested frequently using automated testing. The frequency can be as short as days, hours or minutes in terms of these iterative builds. This approach can still be used for a product such as a marketing campaign but it may not be as easy to build it so quickly or through the use of lots of automation.

The challenge here when using PRINCE2 and agile together is to apply this concept as much as possible. The more it can be applied, the more agile the project will be. In an agile software context one approach is to use test-driven development (TDD) in the creation of software. Although this is a software-specific approach, the fundamental thinking behind it has led to similar techniques that can be used at a higher level and not necessarily in an IT context. One such example is behaviour-driven development (BDD); see Table 11.2. BDD can be applied to both ‘building the right thing’ and ‘building the thing right’ – sometimes referred to by two separate processes called ‘validation and verification’ (or V&V).

The idea of continually writing tests or quality-checking processes before building a product or sub-product may seem counterintuitive to many but this is one of the concepts of the agile way of working. When it works in partnership with developing the product iteratively and refactoring the product (see Table 11.2), this helps to build the appropriate level of quality into the final product.

This can be quite challenging but it is agile best practice and is one of the reasons why the agile way of working has become popular (because it ensures that quality is built into a product).

Term Description

Definition of ‘done’

See Appendix H: The definitive guide to Scrum.

See section 11.4 for an example.

Definition of ‘ready’

A similar concept to the definition of ‘done’ except that this is a list of criteria to determine if work can be started on something such as a user story or a sprint.

See section 25.6.1 for an example.

Test-driven development (TDD)

This is a software development process that uses a very short development cycle whereby:

  • A developer writes an (initially failing) automated test for a new function.
  • The developer then produces the minimum amount of code to pass that test.
  • Finally, the new code is refactored to meet the appropriate coding standards.

TDD is related to the test-first programming concepts of eXtreme Programming (XP) from the late nineties: it requires automation and usually takes place at the ‘unit-testing’ level (i.e. the smallest testable part of a system).

Behaviour-driven development (BDD)

This is a software development process based on TDD. BDD is usually more collaborative and uses the general techniques and principles of TDD in a wider behavioural context (e.g. what the customer may want to achieve). It uses a style of language that is easy for the customer to understand (hence the use of words such as ‘behaviour’ in preference to ‘test’).


In a software context, this is defined by Martin Fowler as ‘...the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure’ (Refactoring: Improving the Design of Existing Code by Martin Fowler).

The same concept can be applied to any product irrespective of whether or not it contains software.

Technical debt

Another term mostly used in the software domain, which is a metaphor referring to the eventual consequences of poor system design, software architecture or the software development itself. The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases the level of disorder in the software and therefore its overall level of quality. In a PRINCE2 context, tolerances may be applied to this, and if the debt is forecast to become too significant it will cause an exception.

Table 11.2 Common agile terms that relate to quality

Previous Section   Next Section