PRINCE2 Agile® Foundation

Quick
Reference
Guide

Official Training Materials

Introduction 1. Key concepts relating to projects and
PRINCE2
The PRINCE2 Agile® Foundation qualification is intended for agile professionals, project managers The definition of a project
and aspiring project managers who want to be able to combine PRINCE2® and agile in the most
Project A temporary organization that is created for the purpose of delivering one or more business
effective way. It is also relevant to delivery team staff, including product owners, Scrum Masters and
products according to an agreed business case.
developers, as well as other business professionals with an interest in iterative and incremental
project delivery through collaborative working.
The PRINCE2 Agile Foundation examination is intended to assess whether the candidate can recall
The six aspects of project performance to be managed
and understand the PRINCE2 Agile project management method (as described in the syllabus). The There are six variables involved in any project, and therefore six aspects of project performance to be
PRINCE2 Agile Foundation qualification is a prerequisite for the PRINCE2 Agile Practitioner exam, managed. These are:
which assesses the ability to apply understanding of the PRINCE2 Agile project management method 1. Costs The degree of permissible overspend or underspend against an agreed budget.
in context.
2. Timescales The degree to which a project is permitted to deliver later or earlier than an agreed
target completion date.

What you will learn

3. Quality How much something can vary from agreed quality criteria.
4. Scope Permissible variation of the plan’s products.
5. Benefits The degree to which it is permissible to underdeliver or overdeliver benefits (realized
or estimated).
Key concepts relating to projects and PRINCE2 6. Risk Limits on the plan’s aggregated risks.
Key concepts relating to projects and PRINCE2 Agile

*
 ow PRINCE2 principles, themes, processes and management products are tailored and/or
H The structure of PRINCE2
applied in an agile context The PRINCE2 method addresses project management with four integrated elements of principles,
The agile ways of working, key terms and techniques themes, processes and the project environment.

The focus areas in an agile context

The PRINCE2 Agile Foundation exam consists of 50 multiple choice questions (MCQ) and requires
the candidate to obtain 55% (28 questions) correct or more to pass.
This Quick Reference Guide may be used by learners to assist in their preparation for the PRINCE2
Agile Foundation certification test. PeopleCert does not warrant that use of this guide will ensure
passing of the exam.

Figure 1.1 The structure of PRINCE2

2 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 3
1. PRINCE2 principles The principles are the guiding obligations and good practices which
determine whether the project is genuinely being managed using PRINCE2.
These seven PRINCE2 principles are:

• Continued business justification For all projects there is a justifiable reason for starting the
project, that justification is recorded and approved, and the justification remains valid, and is
revalidated, throughout the life of the project.
• Learn from experience PRINCE2 project teams learn from experience: lessons are sought,
recorded and acted upon throughout the life of the project.
• Defined roles and responsibilities A PRINCE2 project has defined and agreed roles and
responsibilities within an organization structure that engages the business, user and supplier
stakeholder interests.
• Manage by stages A PRINCE2 project has defined and agreed roles and responsibilities
within an organization structure that engages the business, user and supplier stakeholder
interests.
• Manage by exception A PRINCE2 project has defined tolerances for each project objective, to
establish limits of delegated authority.
• Focus on products A PRINCE2 project has defined tolerances for each project objective, to
establish limits of delegated authority.
• Tailor to suit the project PRINCE2 is tailored to suit the project environment, size, complexity,
importance, team capability and risk.

2. PRINCE2 themes The themes describe aspects of project management that must be

*
addressed continually and in parallel throughout the project. Figure 13.1 The PRINCE2 processes

Adaptation of table 5.1 The PRINCE2 themes The purpose of the PRINCE2 processes are as follows:

Theme Purpose Answers • Starting up a project To ensure that the prerequisites for initiating a project are in place by
answering the question: Do we have a viable and worthwhile project?
Business case To establish mechanisms to judge whether the project is Why?
(and remains) desirable, viable and achievable as a • Initiating a project To establish solid foundations for the project, enabling the organization to
means to support decision-making in its (continued) understand the work that needs to be done to deliver the project product before committing to a
investment.
significant spend.
Organization To define and establish the project’s structure of Who?
accountability and responsibilities. • Directing a project To enable the project board to be accountable for the project’s success by
Quality To define and implement the means by which the What? making key decisions and exercising overall control while delegating day-to-day management of
project will verify products that are fit for purpose. the project to the project manager.
Plans To facilitate communication and control by defining the How? • Controlling a stage To assign work to be done, monitor such work, deal with issues, report
means of delivering the products. How much?
progress to the project board, and take corrective actions to ensure that the management stage
When?
remains within tolerance.
Risk To identify, assess and control uncertainty and, as a What if?
result, improve the ability of the project to succeed. • Managing product delivery To control the link between the project manager and the team
Change To identify, assess and control any potential and What is the impact? manager(s), by agreeing the requirements for acceptance, execution and delivery.
approved changes to the project baselines.
Progress To establish mechanisms to monitor and compare actual Where are we now?
achievements against those planned; provide a forecast Where are we
for the project objectives and the project’s continual going?
viability; and control any unacceptable deviations.
Should we carry on?

3. PRINCE2 processes The processes describe a progression from the pre-project activity of
getting started, through the stages of the project lifecycle, to the final act of project closure.
PRINCE2 provides a process model for managing a project. The seven processes can easily be
scaled and tailored to suit the requirements of all types of projects. They consist of a set of
activities that are required to direct, manage and deliver a project.

4 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 5
• Managing a stage boundary To enable the project manager to provide the project board with
sufficient information to be able to:
PRINCE2 project management team roles
• review the success of the current management stage
• approve the next stage plan
• review the updated project plan
• confirm continued business justification and acceptability of the risks.
• Closing a project To provide a fixed point at which acceptance of the project product is
confirmed, and to recognize that objectives set out in the original PID have been achieved (or
approved changes to the objectives have been achieved), or that the project has nothing more to
contribute.

4. The project environment Organizations often want a consistent approach to managing

projects and tailor PRINCE2 to create their own project management method. This method is
then embedded into the organization’s way of working.

The PRINCE2 management products

PRINCE2 method defines 26 management products, which are products that will be required as part
of managing the project, and establishing and maintaining quality. The management products can be
used with any relevant modifications, for all projects. There are three types of management products:
baselines, records and reports.
The most important PRINCE2 management products from the perspective of tailoring them to agile
Figure 7.3 PRINCE2® project management team roles
ways of working are:

*
• Project brief is used to provide the project board (and possibly other stakeholders) with a The project board is accountable to corporate, programme management or the customer for the
summary of the management stage status at intervals defined by them. In the initiating a project success of the project, and has the authority to direct the project within the remit set by corporate,
process, the contents of the project brief are extended and refined in the PID, after which the programme management or the customer as documented in the project mandate. The project board
project brief is no longer maintained. is also responsible for the communications between the project management team and stakeholders
• Project initiation documentation (PID) is used to define the project, in order to form the basis external to that team.
for its management and an assessment of its overall success. The PID gives the direction and The executive is ultimately accountable for the project, supported by the senior user and senior
scope of the project and (along with the stage plan) forms the ‘contract’ between the project supplier. The executive’s role is to ensure that the project is focused throughout its life on achieving
manager and the project board. its objectives and delivering a product that will achieve the forecast benefits. The executive has to
• Business case is used to document the business justification for undertaking a project, based on ensure that the project gives value for money, ensuring a cost-conscious approach to the project,
the estimated costs (of development, implementation and incremental ongoing operations and balancing the demands of the business, user and supplier.
maintenance costs) against the anticipated benefits to be gained and offset by any associated
The senior user is responsible for specifying the needs of those who will use the project product, for
risks.
user liaison with the project management team, and for monitoring that the solution will meet those
• Project product description is a special form of product description that defines what the needs within the constraints of the business case in terms of quality, functionality and ease of use.
project must deliver in order to gain acceptance. It is used to gain agreement from the user on The role represents the interests of all those who will use the project product (including operations
the project’s scope and requirements, define the customer’s quality expectations, define the and maintenance services), those for whom the product will achieve an objective, or those who
acceptance criteria, method and responsibilities for the project. will use the product to deliver benefits. The senior user role commits user resources and monitors
• Work package is a set of information about one or more required products collated by the products against requirements.
project manager to pass responsibility for work or delivery formally to a team manager or team
member.
• Highlight report is used to provide the project board (and possibly other stakeholders) with a
summary of the management stage status at intervals defined by them. The project board uses
the report to monitor management stage and project progress. The project manager also uses
it to advise the project board of any potential problems or areas where the project board could
help.
• Checkpoint report is used to report, at a frequency defined in the work package, the status of
the work package.

6 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 7
The senior supplier represents the interests of those designing, developing, facilitating, procuring
and implementing the project product. This role is accountable for the quality of the project product
What is PRINCE2 Agile?
(and its components) delivered by the supplier(s) and is responsible for the technical integrity of the PRINCE2 Agile describes how to configure and adapt PRINCE2 so that PRINCE2 can be used in the
project. most effective way when combining it with agile behaviours, concepts, frameworks and techniques.
The project manager is accountable to the project board and ultimately the executive and has the PRINCE2 and PRINCE2 Agile are only suitable for use on projects, whereas agile can be used for
authority to run the project on a day-to-day basis, within the constraints laid down by them. The projects and routine ongoing (business as usual – BAU) work as well.
project manager’s prime responsibility is to ensure that the project produces the required products
The different characteristics of a project and BAU work:
within the specified tolerances of time, cost, quality, scope, benefits and risk. The project manager is
also responsible for the project producing a result capable of achieving the benefits defined in the Table 1.1 The different characteristics of a project and BAU work
business case.
Project characteristics BAU characteristics
The team manager’s prime responsibility is to ensure production of those products defined by the Temporary Ongoing
project manager to an appropriate quality, in a set timescale and at a cost acceptable to the project
Team is created Stable team
board. The team manager is accountable to, and takes direction from, the project manager.
Difficult Routine
A degree of uncertainty A degree of certainty
2. Key concepts relating to projects and
PRINCE2 Agile
What is agile?
The term ‘agile’ is very broad and is viewed in many different ways throughout the agile community.
There is a set of well-known frameworks referred to as ‘agile methods’ and there are also well-known

*
behaviours, concepts and techniques that are recognized as characterizing the agile way of working. But Project direction
there is no single definition of agile, although the Agile Manifesto comes the closest to achieving this: Product is developed / improved
incrementally over time
Project management

Pre- Initiation New or significantly

project stage revised product Goes into production Existing product
(perhaps
incrementally) Batches
Project work Close of features
BAU
Temporary “Backlog” or Ongoing
“to do list”
prioritized

Figure 1.1 The difference between project work and BAU work

NOTE: PRINCE2 Agile can be used on the left-hand side of the dashed line only (for example, for
projects). Agile can be used on both sides (for example, used on projects and for BAU).

Figure 2.1 The Agile Manifesto

Waterfall method
A development approach that is linear and sequential, with distinct goals for each phase
of development. After a phase of development has been completed, the development
proceeds to the next phase and earlier phases are not revisited (hence the analogy that
water flowing down a mountain cannot go back).

8 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 9
Agile frameworks
PRINCE2 Project Agile
Many agile approaches or ways of working are suitable to use with PRINCE2 Agile. The most well- PRINCE2 thinking direction thinking
known and important PRINCE2 Agile® perspectives are: cascades rises up
down
• Kanban A way to improve flow and provoke system improvement through visualization and
controlling work in progress.
• Scrum An iterative timeboxed approach to product delivery that is described as ‘a lightweight PRINCE2 Project
management
framework that helps people, teams and organizations generate value through adaptive solutions
for complex problems.’
• Lean Startup Originally an approach to creating and managing start-up companies, but now
applied to any business, to help them deliver products to customers quickly.
Product
Agile delivery

The rationale for blending PRINCE2 and agile

PRINCE2 is the most commonly used project management approach in the world, and it is = Area of strength = Blending of
increasingly being used in conjunction with agile. the philosophies

PRINCE2 and agile each have their own strengths and when combined they complement each other
and create a holistic approach to managing projects in an agile way. Figure 3.1 Blending PRINCE2 and agile together

• The strength of PRINCE2 lies in the areas of project direction and project management.
Eight important guidance points about PRINCE2 Agile

*
However, it provides little focus on the field of product delivery.
• Conversely, agile has a very strong focus on product delivery but relatively little on project In order to correctly understand PRINCE2 Agile one must be aware of the following eight guidance
direction and project management. points which are intended to provide clarity where there is potential for ambiguity, and accuracy
where there may be misconceptions. These eight guidance points are shown in the Table 2.2.

Table 3.4 Summary of the key points in Chapter 3

Key point
1 PRINCE2 (6th edition) is already enabled for use with Agile.
2 PRINCE2 is suitable for any style of project and is not a ‘traditional’ project management
approach as is typically contrasted to Agile.
3 PRINCE2 Agile is for any project and not just for IT projects.
4 ‘IT only’ frameworks and techniques are mentioned in PRINCE2 Agile but not extensively.
5 There is much more to Agile than the Scrum framework. Agile is not Scrum.
6 The most ‘commonly used’ Agile approaches are Scrum and Kanban, but they are not
suitable for managing a project in isolation. However, they can be effectively used in a
project context.
7 The term ‘Agile’ refers to a family of behaviours, concepts, frameworks, and techniques.
8 Using Agile on a project is not a question of ‘yes or no’: it is about ‘how much’.

10 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 11
3. PRINCE2 Agile guidance, tailoring and Agile behaviours
techniques When tailoring PRINCE2 to work in an agile context a PRINCE2 project manager and the project board
will need to monitor specific behaviours, which need to function smoothly for agile to operate in the
most effective way. These behaviours are:
Guidance on applying the PRINCE2 principles Transparency The more information that is out in the open, the better this is for the agile way
PRINCE2 is principles-based and all seven of the principles are applicable when combining PRINCE2 of working. It enables speed, clarity and engagement, even if the news is not so good. The most
with agile. These principles are: important elements of this principle come in the form of the common agile values of honesty, trust,
integrity and respect. This openness is an essential ingredient for an agile way of working.
1. Continued business justification The rationale behind creating a minimum viable product
(MVP) needs to be understood, and attention should be paid to it throughout the project by the Collaboration A motivated and respectful team is greater than the sum of its parts if people work
project management team. together and provide cover for one another. Collaboration is not just internal to the team: it involves
external collaboration with all stakeholders. Fully engaging with customers and working with them,
2. Learn from experience Many agile concepts support this principle and as many of them as
rather than for them, will create shared understanding and ownership of goals and outputs.
appropriate should be used in order to provide the techniques for continual learning. Examples
of this include shortening the feedback loop to the customer, continual customer involvement, Rich communication People should always use the most effective channel to communicate. Using
inspect and adapt, retrospectives and Kaizen. face-to-face and/or visualization are many times faster and more effective than words on their own. A
3. Defined roles and responsibilities Additional agile roles will apply at the delivery level and rich communication environment should be created, allowing information to pass freely in a culture
they should be mapped and merged carefully to the PRINCE2 roles. of commitment and trust. There is still a need for documentation, but by using other more effective
channels, it can be replaced or complemented and greatly reduced.
4. Manage by stages Significant timeboxes such as releases should be carefully planned to integrate
with, and fit into, management stages. In situations of high uncertainty many short stages can be used Self-organization The people closest to the work will usually know best how to get the job done.
to ensure that control is maintained and a fail fast/learn fast environment exists. Therefore, people should be trusted to do it. Self-organizing creates mutual respect. A project
5. Manage by exception It is vital to see this as at the heart of empowering people to self- manager can leave a team manager to focus on product delivery, thereby making the team manager
organize and stay in control with the appropriate level of governance when using PRINCE2 and feel trusted. This principle includes the way the team works and the way team members behave

*
agile together. Working in an agile way places a greater emphasis on allowing tolerance on what towards one another.
is delivered and restricting the tolerance on time and cost. Exploration Projects are difficult, and in order to create ‘the right thing’ you need to be able to work
6. Focus on products Product descriptions, quality criteria and quality tolerances can be out what ‘the right thing’ is. Frequent iteration and rapid feedback loops in any form provide an
prioritized and decomposed in order to make flexing what is being delivered possible and opportunity to learn. Learning helps to improve the products. Feedback will not just happen; it needs
therefore make it easier to stay in control and focus on the delivery of value. to be sought out collaboratively with people such as the customer, customer representatives, other
7. Tailor to suit the project environment PRINCE2 Agile incorporates an agile assessment tool team members or stakeholders.
(the Agilometer), which enables further specific tailoring by assessing the risks associated with
the agile way of working with respect to the project environment.

Spike/spiking
Timebox A temporary piece of work used to understand more about a given situation. It may take
the form of a prototype or some research and is often used to reduce uncertainty from a
A finite period of time when work is carried out to achieve a goal or meet an objective. The
technical or customer viewpoint. Experiments are similar.
deadline should not be moved, as the method of managing a timebox is to prioritize the work
inside it. At a low level a timebox will last a matter of days or weeks (for example, a sprint).
Higher-level timeboxes act as aggregated timeboxes and contain lower-level timeboxes (for
example stages).

12 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 13
 • Customer representative is partially assigned to the delivery team or the senior user in order to
Agile and PRINCE2 themes contribute, or to be canvassed about, specific information that may be of use to the project. This
PRINCE2 uses themes to describe aspects of project management that must be addressed is a consultative role that provides general or detailed information relating to specific areas of the
continually. It is essential to use all of the seven themes. PRINCE2 Agile provides a guidance how to project that may be involved or impacted.
tailor and adapt PRINCE2 themes so that they can be used in the most effective way when combining • Supplier subject matter expert is assigned to the delivery team, provides the appropriate
them with agile way of working. technical skills to build and initially quality check the project product (and its components). They
should be working collaboratively with the customer SME(s) and other customer representatives
Business case theme and agile to evolve the products so that they deliver what is required in order to ultimately achieve the
highest value possible for the customer.
When used in agile context, business case theme may contain more information and emphasis
on the tolerances around benefits. The business case could show the amount of product being • Supplier representative is partially assigned to the delivery team or to the senior supplier
delivered in the form of a best-case, a worst-case and an expected-case scenario in relation to the to contribute, or to be consulted about, specific technical or specialist information that may
amount of the final product that may be delivered or flexed. be of use to the project. This is a consultative role that provides general or detailed technical
information relating to specific areas of the products being delivered.
It may also be appropriate to explicitly define what would constitute a minimum viable product (MVP),
• Delivery team quality assurance is responsible for independently checking that the project
as well as some indication of priorities within the overall scope and related quality criteria.
product is fit for purpose from a customer and supplier perspective at the delivery level. This
When creating a business case, it is essential to understand how the incremental delivery of a should be carried out collaboratively by engaging with the customer and supplier SMEs in an
product and the value associated with it could impact project viability and also the ability to achieve iterative style of working as the project product’s components and the understanding of them
the early delivery of some benefits. evolve. Customer and supplier quality assurance can be carried out by two separate roles if
appropriate.

Benefit 3
The measurable improvement resulting from an outcome perceived as an advantage by Senior Senior
Executive
one or more stakeholders, and which contributes towards one or more organizational user supplier

*
Key
objective(s).
Delivery team
Project
manager
Organization theme and agile Team
manager
Additional delivery-level roles may need to be added, and the most common agile roles should be
mapped appropriately to the roles of the project management team structure. 2 1
Supplier
Understanding is required of: Customer SME 1
Customer SME 1
representative(s) Supplier
• how a self-organizing delivery team operates and how this relates to the team manager role representative(s)
• the responsibilities of the most common agile roles such as product owner, Scrum master, agile 4 (Supplier
coach, business ambassador (Customer SME 2)
SME 2)
• the potential limitations of the product owner role, where a wider view of the customer is needed,
such as with multi-team projects
rance 5
• how the senior user role acts more as a ‘super product owner’ than a conventional product owner Team quality assu

• where more than one team is involved, how Scrum masters will liaise with the project manager.

The use of management by exception principle is essential to enable PRINCE2 and agile to be Figure 10.4 An example of an organizational set-up for a project with one team
combined, to empower the project management team and enable it to self-organize within clearly
defined boundaries.
PRINCE2 Agile provides the following set of generic agile roles that can be used if desired:
• Customer subject matter expert is assigned to the delivery team, plays an active part by acting
as a representative of all of the customer stakeholders with a responsibility for ensuring that
the project product (and its components) is understood and is correct at the detailed level. The
person carrying out this role probably wants, or needs, the final product and is motivated for the
project to succeed as they are impacted or helped by its delivery.

14 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 15
 Customer
representative (s)
Senior
user 1
Executive
Senior Backlog
Senior supplier
user 2
1 A list of new features for a product. The list may be made up of user stories which are
Customer
structured in a way that describes who wants the features and why. It is also a generic
representative 2 Project
manager
term that can be defined in terms of releases, sprints and products.

Supplier
representative

Team Team Team

manager manager manager Epic
Customer Supplier Customer Supplier Customer Supplier
A high-level definition of a requirement that has not been sufficiently refined or
SME SME SME SME 1
3 CQA Supplier
5 SME 1
Customer
SME 1
Supplier
understood yet. Eventually, an epic will be refined and broken down into several user
SME 2
8
QA 9
SQA
SME 2
Customer
SME 2
stories or requirements.
SME 3
QA coach
7

Customer
Customer
representative
Risk theme and agile
representative
6 Coach 7 The agile way of working addresses many risk areas such as avoiding too much detail at the start of
(project support)
a project. However, agile comes with its own set of potential risks and these need to be proactively
Figure 10.5 An example of an organizational set-up for a project with many teams managed.
Many agile techniques address risks, for example daily stand-up meetings, frequent delivery of
products, frequent use reviews, customer interaction and empowered teams organizing themselves
Quality theme and agile to deliver the right thing at the right time.
It is important to understand the difference between scope and quality when defining customer

*
quality expectations, acceptance criteria, product descriptions, quality criteria and quality tolerances. Change theme and agile
They need to be defined in such a way that flexing what is being delivered does not compromise the
fitness for purpose of any product, or ultimately the final product. The agile way of working embraces change and responds to it. The PRINCE2 approach to change
control needs to allow for this and helps to create a more accurate final product. The appropriate
The use of agile concepts and techniques such as the definition of ‘done’ and the definition of ‘ready’
definition of product descriptions, quality criteria, quality tolerances and work packages is important.
can be used to define quality criteria and acceptance criteria.
They can be defined in such a way as to allow for change, while at the same time creating a clearly
The frequency of quality checking (in the form of reviews or tests) will have a significant impact
defined baseline that can prevent a change to the very purpose of a product going undetected.
on how a project is planned, as this will affect the iterative and incremental delivery of the project
product (and its components) and how they are released. Configuration management will need to be set up in a way that also helps to embrace change, as it
may happen frequently.

Plans theme and agile

Progress theme and agile
Many agile techniques and approaches exist in this area. They focus on the effort related to features
(for example, sprint planning) and often appear in an informal, low-tech, visible format such as a Many agile techniques apply in this area where the emphasis is on tracking what is being delivered in
simple list or backlog. the form of such things as velocity, lead times or value. This is as opposed to tracking time and cost,
which are not suitable as a measure of a project’s progress. Tolerances would be set in accordance
Planning is often done empirically. Agile typically looks at how much can be produced in a fixed
with this.
timeframe such as a sprint or a release (or how much value can be delivered). This is often shown at
the start in the form of a burn chart that can then be tracked.
Gantt charts may be of value at the higher levels of plan, but they should be synchronized to the
agile way of working and should avoid the duplication of information that is being held in the form of
backlogs.

16 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 17
Tracking progress will depend on the situation and what people need information on. If it is within a
sprint, then burn-up or burn-down charts may suffice. If it is across releases, then showing the value
Agile and PRINCE2 processes
accrued and how this relates to the business case may be more appropriate. PRINCE2 is a process-based approach to project management and has seven processes (containing
activities) which apply to all levels of a project. All seven processes are required, and agile needs to
The frequent delivery of products that meet the appropriate acceptance criteria/quality criteria is the
be incorporated into all of them in some form. The amount of agile that is relevant to each process
primary source of information with respect to progress and provides the basis for forecasting future
varies significantly, and therefore the amount of tailoring required varies accordingly.
progress.

Information radiator
A general term used to describe the use of walls or boards containing information that can
be readily accessed by people working on the project. It can contain any information,
although it would typically show such things as work to do and how work is progressing.

Stand-up meeting
A short meeting to assess progress. Typically lasting 15 minutes or less, they involve
describing work that has been done, work still to be done and any problems being
encountered.

Velocity

*
A description of the rate of progress a team is making. For example, if a team is
completing 20 user stories per week, then this is their velocity and it can be used to
empirically forecast their future rate of progress (assuming that the conditions remain the
same).

Figure 13.1 The PRINCE2 processes

18 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 19
 Typical agile project process (sprints only) SU – Starting up a project PB – Product backlog
IP – Initiating a project RB - Release backlog
CS – Controlling a stage
Vision
and
product Potentially
Sprint shippable
backlog backlog Sprint product

2–4 weeks

PB PB
SU IP CS CS CS
Stages
Sprints

Typical agile project process (releases and sprints)

Vision Potentially
and shippable
product Release Sprint product
backlog backlog backlog Sprint Figure 14.1 Overview of starting up a project

*
PB PB
RB RB
SU IP CS CS CS
Stages
Releases
Sprints

Figure 16.4 How typical agile processes would relate to the PRINCE2 process model

PRINCE2 Agile guidance on starting up a project and

initiating a project processes
In PRINCE2 it is important that a project gets off to a good start with the appropriate amount of
upfront work. Most upfront work done in some agile environments only concerns getting ready for
delivery. PRINCE2 provides more rigour to this work by putting more structure around what ‘being
ready’ means (during the initiating a project process), and also making sure it is worth getting ready
in the first place (during the starting up a project process).
Collecting enough information means that a lot of areas need to be looked at because they can all
impact the business case in one form or another (for example, risks, organizational structure,
quality planning, communication planning and how the project is tailored).
As part of these two processes (starting up a project and initiating a project), the suitability of using
agile needs to be assessed. The use of agile will bring many advantages but it will also bring with it a Figure 16.1 Overview of initiating a project
set of risks if agile is used inappropriately. This is assessed using the Agilometer.

20 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 21
Guidance for tailoring PRINCE2 management products Directing a project process and agile
Project brief may have an informal format and presentation when working with agile. The project In PRINCE2 Agile, it is vital to ensure that management by exception is operating effectively for the
definition in an agile context is preferably more outcome-based than solution-based and is also whole project management team as this creates an environment conducive to the agile way of
likely to outline the areas of scope and quality criteria that have flexibility in the sense that they can working where people are empowered and self-organize.
be prioritized. The project approach will contain an agile element describing the use of agile, which
In terms of progress reporting the project board should expect more emphasis to be placed on the
techniques and approaches have been selected, and how the agile element will benefit the project.
amount being delivered, and the information flows may be regular, rich and informal. The project
The delivery-level roles in the project management team structure will have more detail and may be
board may even attend reviews.
included. Due to the desire for incremental delivery of benefits there will probably be more detailed
information on the impact this may have on areas such as operations and maintenance Decision-making could be further enhanced by attending key demos and may be based more on
information pulled from the project as opposed to formally reported.
Project initiation documentation in an agile context should be created with the view of ‘enough
and no more’. That is to say, it should be complete, but it needs to be as concise as possible and at
the appropriate level of detail. Otherwise, its role as a form of communication will suffer. This product
(or parts of it) may exist on an information radiator if appropriate for the project environment.
Business case needs to be expressed in a way that allows for flexing of the amount being delivered.
The MVP would need to be identified so that an exception can be raised if this is forecast to be
delivered later than expected.
Project product description: In alignment with the business case this is likely to focus on defining
a product with a close link to a desired outcome in preference to just defining a solution. It may
be created as part of a workshop (for example, a visioning workshop). The purpose of this product
should be clearly visible to all irrespective of the project environment (for example, it should be
clearly displayed on a wall or clearly displayed on the intranet). It is an important product when
combining PRINCE2 with agile in that it defines the ultimate output (the final product) and the

*
outcome, which needs to be clear and precise so that the iterative and incremental nature of agile
does not go off track.
Further guidance on using these processes in an agile context:
• The project product description (and the business case) should be defined with more focus on
how the output can be described so that the outcomes and benefits can be adjusted during the
project.
• The high-level and intermediate-level requirements are likely to be held as a list (backlog) which
may take the form of a spreadsheet or a low-tech list on a wall. Figure 15.1 Overview of directing a project
• The mapping of existing agile roles to the PRINCE2 roles will be defined and understood.
• Workshops are likely to be used to collaboratively create and understand deliverables.
• Levels of uncertainty need to be explicitly stated as these may affect the choice of agile
techniques such as the use of prototyping, spikes or experiments and the choice of how long to
make timeboxes.
• An assessment should be made of the impact of frequent releases on areas such as how quality
will be managed and how the frequent delivery of products will take place.

Applicable agile events and artifacts for starting up a project and initiating a project include:
• (Previous) project/release retrospectives
• Vision
• Product backlog
• Definition of ‘done’
• Release planning
• Information radiators.

22 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 23
 Highlight report may contain additional information on releases (for example, what has been
Controlling a stage process and agile released and what benefits have been enabled). May be delivered verbally. Could be in the form of an
The nearest equivalent to a stage within agile would be a higher-level timebox that acts as a container information radiator and/or a burn chart. If the information is transparent then this can be extracted
for a set of lower-level timeboxes. This may be referred to using terms such as release, iteration (or ‘pulled’) by the project board when required.
or increment. These could involve more than one team and they would be typically managed by a
Checkpoint report would typically be in the form of an information radiator and/or a burn chart.
project manager or product manager.
Could be replaced by a daily stand-up or Scrum meeting with the agreement of the delivery team but
A management stage is slightly different from such concepts as a release, iteration or increment in would need to avoid being seen as a ‘reporting to’ mechanism. If the information is transparent then
that it focuses on the commitment of resources and grants the project manager the authority to this can be extracted (or ‘pulled’) by the project manager when required.
spend within the context of ongoing project viability.
Applicable agile artifacts for controlling a stage include:
Further guidance on using controlling a stage in an agile context:
• Product backlog
• Planning, scheduling and estimating are likely to be carried out as a collaborative team-based • Release backlog
exercise.
• Sprint backlog
• At the delivery level team members typically select the next piece of work to be done. As a result,
• Burn charts
work is typically not assigned to specific team members.
• Information radiators
• A work package may contain several timeboxes (for example, in the form of sprints) and although
each one will deliver something, they may not necessarily deliver something into operational use. • Impediments from daily stand-ups
Work packages provide the flexibility (for example,. through tolerances) needed to enable teams • Potentially shippable product
to self-organize, and their sign-off may be informal. Reviews and demos at the end of a sprint • User story acceptance criteria
or a release provide rich and regular feedback to the customer as a means to validate that the
Applicable agile events for controlling a stage include:
acceptance criteria for the agreed work package have been met.
• Reporting of progress during a sprint within a release to which it belongs is typically done via • Release planning
information radiators. Progress is more likely to be shown as a burn chart rather than a Gantt • Sprint planning

*
chart. • Daily stand-ups
• Reporting of progress at the end of a sprint or a release is done via the sprint or release review • Sprint reviews
and the optional product demo. • Sprint demo
• Monitoring and forecasting in general is more likely to be in an empirical style (based on • Sprint retrospectives
evidence).
• Release review
• Project manager will focus on flexing the scope and the quality criteria of the defined products.
• Release demo
• Sprint and release retrospectives provide an opportunity for risks and/or issues that may have
• Release retrospectives
been missed in the daily stand-ups or review sessions to be highlighted by the team.
• User acceptance (during a sprint demo or release demo)

Guidance for tailoring PRINCE2 management products

Work package Although it is a formal interface this would typically be carried out in a collaborative
way and negotiated by the project manager and the team manager and perhaps with the delivery
team as well. One or more work packages may be collaboratively defined as the output from a sprint
planning meeting. A work package should be defined in such a way as to create a safe boundary of
control, while at the same time creating the space for the delivery team to create the product (or
products) in the most effective way through self-organizing. A work package may include one or more
releases and one or more sprints. Therefore it is essential from the start to get clarity on how work
packages will be designed and how they will operate on a project.

24 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 25
 Applicable agile artifacts and events for managing product delivery include:
Managing product delivery process and agile
• Release backlog
The agile way of working focuses very strongly on product delivery and the ‘management’ of product
• Sprint backlog
delivery.
• Information radiators, burn charts
When combining PRINCE2 with agile, the managing product delivery process and the use of work
packages needs to be seen as a vital interface and linking process. It is the glue that joins together • Impediments
project management (where PRINCE2 provides lots of guidance) with product delivery (where agile • Potentially shippable increment
provides lots of guidance). • Release planning
At the heart of this interface is the definition of a work package, therefore it needs to blend the • Sprint planning
complementary styles of PRINCE2 and agile. Work packages should be collaboratively defined by the • Daily stand-ups.
project manager, team manager and the team (this may take place as part of a sprint planning or
release planning meeting).
Managing a stage boundary process and agile
In some ways the work package is like a handshake. If this partnership is built correctly, it brings
There is a similarity between a major review of a release and the managing a stage boundary
the benefits of control in a project environment, while at the same time allowing the delivery teams
process. In both, progress can be reviewed with respect to how much value or benefit has been
enough room to negotiate the uncertainties they will meet when working at the detailed level.
delivered, how the team is performing, how the processes are working, and how the project is
This process and the use of work packages may not result in significant changes in how agile teams progressing with regard to quality and product delivery, planning the next release and assessing the
work. The teams need to understand the role they play in a wider PRINCE2 context and that they project’s exposure to issues and risks.
need to provide information in a timely manner to the project manager to enable them to carry out
their duties effectively.

*
Figure 20.1 Overview of managing product delivery

Figure 19.1 Overview of managing a stage boundary

Further guidance on using managing product delivery in an agile context:
• The formality of reporting arrangements should be agreed (for example, low-tech burn charts).
• Checkpoint reports may be done verbally or as a group.
• Tolerance with respect to scope and quality could be defined in the work package (as well as in
the product description(s)).
• The product description(s) contained in the work package may be defined at a level that clearly
describes what the team needs to deliver, while at the same time not being so detailed that they
restrict the team and how they create those products.
• There should be an agreement that the team plan will evolve, as it may be based on the self-
allocation of work and because empirical forecasting is being used.

26 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 27
Further guidance on using managing a stage boundary in an agile context: End-of-project activities should already be in an advanced state of completeness due to frequent
releases gradually improving how project closure is done and populating information. For example:
• Review how much is being delivered (and the quality of it) compared with what had been planned.
This would include comparing the amount of value being delivered with the amount of cost • Project/process evaluation should be ongoing through the frequent use of retrospectives.
incurred to create that value. • Continual use of ‘inspect and adapt’ would mean that the lessons report has been created as the
• The appropriate use of agile could be reviewed in case risks are surfacing in certain areas. project has gone along, and many of the lessons would have already been actioned.
• Release planning would typically be reviewed, for example to make a decision either to increase • User acceptance would be happening regularly, although care should be taken to ensure
the frequency of the releases or not. that user acceptance is not too informal when closing the project in order to ensure that the
• Decide on which of the suggested improvements to the way the teams are working (perhaps customer’s quality expectations and acceptance criteria have been met.
created during a release retrospective) can be reasonably expected to be adopted in the next • Operational handovers (and acceptance) are likely to have happened many times due to the
release. incremental delivery of products, so the final handover should be a routine event.

Applicable agile artifacts and events for managing product delivery include: • Training and technical documentation would be finalized, as it would have been created iteratively
and incrementally throughout the project.
• Product backlog (done/not done, value enabled)
Applicable agile artifacts and events for closing a project include:
• Release backlog (done/not done, value enabled)
• Potentially shippable increment • Project vision

• Information radiators • Product backlog (done/not done)

• Release planning • (Final) release backlog (done/not done)

• Sprint planning • Potentially shippable increment

• Release reviews • Information radiators

• Release retrospectives • Outstanding impediments

• Information radiators
Closing a project process and agile

*
• Release review
• Project/release retrospective.
Project closure may take the form of a workshop where the original baseline is checked in relation
to the final outputs and outcomes of the project, and preparation for closure authorization can take
place. This may include a review of the final release. What to fix and what to flex?
One of the most important concepts that exist within PRINCE2 Agile is that it focuses on flexing what
is being delivered, as opposed to focusing on flexing time and cost or flexing time and resources.
PRINCE2 does not place emphasis on any of the six aspects of project performance over and above
the others. It sees them as equally significant and to be managed according to the needs of a
particular project. However, PRINCE2 Agile does define what to emphasize by giving guidance on the
use of tolerance levels (for example, permissible deviations from what is planned) for the six aspects
in terms of which should be fixed and which ones should vary (or flex).

Figure 20.1 Overview of closing a project

28 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 29
Table 6.1 How PRINCE2 Agile views tolerances for the six aspects of a project: fix or fix and flex?
The five targets
Aspect Tolerance Guidance Summary It is not enough just to understand how to flex what is delivered; it is essential to understand why.
Time Zero tolerance for extra time on all levels of plan Fix The thinking behind being flexible with what is delivered is based around five targets, which when
Cost Zero tolerance for extra cost on all levels of plan Fix taken together provide a compelling case for moving to this way of working. These five targets are:
Quality Not all acceptance criteria and quality criteria are equally Fix and flex
important so they can be prioritized in the project product 1. Be on time and hit deadlines Being on time and hitting deadlines has many very significant
description and the product description. advantages: delivering early realization of benefits; helping with planning (for example,
Zero tolerance for the customer’s quality expectations and dependencies between projects); giving confidence with progress; reducing the likelihood of
acceptance/quality criteria that are essential. cost overruns when resources are fixed; improving reputation (for example, with the customer).
Tolerance may be used for the customer’s quality expectations
and acceptance/quality criteria that are desirable but not 2. Protect the level of quality Ensuring that the level of quality is protected and regarded as vital
essential. is of paramount importance to a project. This will lead to a lower cost of ownership throughout
Scope Not everything the project aims to create is of equal importance, Fix and flex the lifetime of the final product.
so they can be prioritized.
3. Embrace change Embracing change by seeing it not only as inevitable but also as a positive
Zero tolerance for products that are essential.
Tolerance may be used for products that are desirable but not influence on a project allows for a more accurate final product.
essential. 4. Keep teams stable Do not add people to a team in order to try to go faster. Keeping a team
Benefits Zero tolerance for the level that is defined as ‘minimum viability’ Fix or flex stable over the short term removes the temptation to add people to a team in order to catch up
in the business case. with work when in reality it is more likely to have little or no effect.
Tolerance may be used above the level that is defined as
‘minimum viability’ in the business case. 5. Accept that the customer does not need everything Accepting the premise that not
Risk Zero tolerance for risks above the level that the project board Fix or flex everything defined in the initial stages of a project must be delivered is wise. It inevitably turns
decides must be escalated. Tolerance may be used for risks that out that many things do not add enough value to warrant delaying the project because of them.
are below this level.

*
Time Cost
Fix Don’t flex

Benefits Fix and Risk May flex

flex

Quality Fix and Scope Flex

(criteria) flex

Figure 6.1 Applying tolerances to the six aspects of a project

30 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 31
4. The agile ways of working, key terms and
techniques
Sprint
Scrum A fixed timeframe (typically of 2–4 weeks) for creating selected features from the backlog.
Scrum is a lightweight framework that helps people, teams and organizations generate value through
adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment with the following: Lean Startup
1. A Product Owner orders the work for a complex problem into a Product Backlog. Lean Startup is a method to grow new businesses, and develop existing ones, through product
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint. innovation in uncertain markets. There are many ideas and concepts that can be taken from it that
add value when combining PRINCE2 with agile.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat. The core concepts of Lean Startup that apply to PRINCE2 are:
• build, measure, learn
• create a minimum viable product (MVP)
• fail fast (in PRINCE2 this is coupled with ‘learn fast’)
• validated learning.

The Scrum artifacts

*
Scrum master
A Scrum role that is responsible for ensuring Scrum is understood and enacted and that
the Scrum team adheres to Scrum theory, practice and rules

Product owner
The role assigned to managing the product backlog in order to get the most value from it
by ordering and prioritizing it.

32 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 33
 User stories
IDEAS
User stories are a very popular technique used throughout agile. The thinking behind user stories is
quite simple and if some basic guidelines are followed correctly their use can be quite effective. This
LEARN BUILD simplicity only goes so far and user stories need to be complemented by a degree of rigour to gain
the most benefit from this technique.
The exact format can vary but will be based on describing ‘who, what and why?’:
As a <role>,
I want to <function>,
DATA
PRODUCT so that <benefit>.

MEASURE
A good user story
#37 Who

AS A Stock controller
Minimize TOTAL time through
Figure 20.8 The build–measure–learn the looploop from Lean Startup
feedback
What
I WANT TO Know if my stock level
is very low
Why
SO THAT I don’t run out and fail to
Minimum viable product fufil a customer’s order
Business
value Effort
In a PRINCE2 Agile context, the term MVP broadly aligns with the Lean Startup view that it 8 2 PTO for quality criteria
is a ‘version of the final product which allows the maximum amount of validated learning
with the least effort’. This should not be confused with the viability of the project as a

*
whole. Typically, an MVP would be delivered as early as possible during the project.
A user story of limited usefulness
It is important to note that an MVP is about learning; it may not go into operational use
and may be in the form of a simple experiment or prototype. AS A Store manager

I WANT TO Manage a store

Retrospectives SO THAT The store is managed effectively

The retrospective is a very common technique, used regularly when working in an agile way. It
involves looking back and reflecting on how things went in terms of how a team worked, in order to
make improvements. A retrospective is a type of review that specifically looks at the way of working
Figure 25.3 A good user story and a poor one
as opposed to looking at what was produced (for example, sprint review).
The most important point is that retrospectives must be planned, structured, and facilitated. If
they are run as an unstructured meeting, they can become ineffective. How to run a retrospective
is decided by the team, so it may become quite informal; however this does not imply any lack
of structure. Retrospectives need to be planned, and they also need to be adapted to keep the
participants stimulated. Retrospectives are only as good as the contributions made by the people
who take part.
A retrospective needs to carefully draw out the learnings from a group, analyse them and then distil
them into decisions and actions that ensure the continual improvement of the way the team works.
The best way to improve is little by little and often. This applies to a sprint, a release, a stage or the
whole project.

34 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 35
 Definition of ‘done’ Burn-down Burn-up
A set of criteria that is used to determine if a piece of work or a collection of work items is
completed. Something is either ‘done’ or it is ‘not done’. Work
Effort Work
Actual added removed
Effort
remaining
Total work
Definition of ‘ready’ Ideal

A set of criteria that is used to determine if a piece of work is ready to be started.

Actual

Workshops Time Time

In agile terms, a workshop is generally regarded as an activity where several people come together to
Figure 15.1 Burn-down and burn-up charts
achieve an objective by harnessing the interactions and creativity of the participants. The ideal way to
run a workshop is by using a neutral facilitator who has no stake in the outcome. Without a facilitator
the group will need to police itself, which will be difficult because participants will be concentrating on Agile Estimation (points and T-Shirt sizing)
creating the content to achieve the objective of the workshop.
One of the most popular techniques used in agile environments is to estimate the work to be done
Preparation is essential for a successful workshop, and this can take as long as the workshop itself. using a points system. This technique can be used for any type of plan in PRINCE2. The principal
Typical steps would include: thinking behind this technique is to start estimating by using ‘relative’ estimates (not ‘actual’
• Workshop objective why the workshop is taking place and what is it looking to achieve estimates) and to do so by harnessing the knowledge of the whole team in a way that everyone can
• Attendees who should attend to ensure that the workshop objective is met contribute without being prejudiced by other team members.

*
• Agenda what steps should take place during the workshop The most common form of relative estimation is achieved by giving requirements or user stories a
• Logistics venue, room layout, refreshments, and equipment points value that means something relative to another requirement or user story. Creating these
relative estimates is carried out as a team, where each team member simultaneously gives their
• Pre-reading what do the participants need to know in advance to enable a workshop to run as
opinion by using pre-numbered playing cards or pieces of paper showing their chosen points value.
smoothly as possible?
There are many variations of numbering systems used and most are based on the Fibonacci
sequence of 1, 1, 2, 3, 5, 8, 13, 21, 34, etc. Another very popular technique is called ‘T-shirt sizing’.
Burn charts This involves classifying each requirement or user story as being either small (S), medium (M), large
One of the most popular techniques in agile environments is to display progress using burn-down (L) or extra-large (XL) and so on.
charts and burn-up charts.
Burn-down charts are used to show how much work remains, whereas burn-up charts are used to Working agreements
show how much work has been done. Both aim to provide two important pieces of information: What
Creating working agreements is a concept that is used to evolve the effectiveness of a self-organizing
is the situation regarding progress? At the current rate of progress what will be the situation at the
team. This is achieved by collectively developing a set of team guidelines, or rules, to bring some
end of this time period (for example, sprint, release, stage, project)?
structure to how the team works and behaves.
These agreements can operate at many levels. Some of them may relate to concepts, such as values,
while others may relate to simple rules about how long a stand-up meeting lasts, or agreeing the
core working hours for the team. They are created and reviewed by the team members themselves
(typically during a retrospective) and their purpose is to improve the effectiveness of the team by
reducing mistakes and promoting successful behaviours and practices.
Typically, they are made visible (for example, displayed on the wall) and the team develops them over
time.

36 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 37
5. The focus areas in an agile context Requirements
There are many terms that are used to describe what a product does or how well it does it. In
Agilometer PRINCE2 Agile the conventions in table below are used.

In order to tailor PRINCE2 in the best way possible it is important to assess the context that a project Table 25.1 Requirements and equivalent terms
exists in with regard to the environment and the working relationships. To achieve this, PRINCE2 Agile
has an assessment tool called the Agilometer to answer the question of ‘How agile can we be on this Approximate level Preferred PRINCE2 Agile Possible equivalent
project?’. The aim of the Agilometer is to provide further guidance (with respect to agile considerations) of detail terms terms
that will create a level of control and predictability, without becoming overly prescriptive. The highest Project product description Vision

The Agilometer looks at six key areas, and the project manager is responsible for canvassing the High level Product group Epic, feature, function, theme,
Project product description scope
key stakeholders involved in the project as to what values to give each category. Each category is composition
represented on the figure by a slider. It is important to see each slider in isolation and not to create High-level requirement
an average score across all areas.
Intermediate level Product description Epic, feature, function, coarse-
The Agilometer shows where there are risk areas with using agile. It also shows the opposite: for Intermediate-level requirement grained user story
example, where there are benefits with using agile. Low level Product description User story, fine-grained user
Sub-product story
Suitability sliders Low-level or detailed requirement

1 2 3 4 5

Low Flexibility on what is delivered High

*
Low Level of collaboration High

Low Ease of communication High

Low Ability to work iteratively and deliver incrementally High

Low Advantageous environmental conditions High

Low Acceptance of agile High

Figure 24.1 The Agilometer

38 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 39
 The biggest problem in communication lies in the fact that people find it relatively difficult to process
the large amount of information in the form of written word (big reports). Often parts are not read
or misinterpreted. Try to avoid the use of email as an important management tool. Face-to-face
meetings is likely to achieve a lot more in a very short span of time.
The final
Project
output A LOT
product
from the
description project
Is composed of High
(composition)

Product Product Product

Visualization
group group group Higher-level
requirements
(epic)

Product * Product

Level of detail
description description

(Interm ediate?)
(A) (B) NONE
As a WORDS VOICE FACE TO FACE
I want to Channel
So that Figure 26.1 Factors that may improve the quality and speed of communication

*
Lower-level
requirements Frequent releases
A fundamental concept of any agile method or approach is to frequently deliver something of use.
*A product description could be There are many advantages associated with this such as:
represented by: Low
(A) A detailed requirements list or • It enables an early delivery of benefit to the customer.
(B) A user story” • It allows for feedback.
Note
• It is likely to reduce risk (for example, of delivering the wrong product).
Requirements decomposition may only need 2 or 3 levels
(high level and low level (detailed)) or (high level, intermediate level and low level (detailed)) • It gives confidence about how the project is proceeding through visibility and evidence.
• It fosters engagement with project stakeholders.
Figure 25.1 Possible requirements decomposition and equivalent terminology
• It makes releasing easier and perhaps second nature.

Release planning needs to be incorporated into the PRINCE2 plans. A project plan would need to
Rich communication clearly show how many releases were expected throughout the project, when they will take place and
‘Communication problems’ are regularly cited as a difficulty faced by people working on projects. what features are intended to be released. The same applies to a stage plan, albeit with a shorter
This can often be the most significant problem encountered. Because effective communication is horizon. The different levels of plan would need to be synchronized with respect to release planning.
so important when a group of people come together to create something, it needs to be proactively
addressed and managed throughout a project. Effective communication is fundamental to the agile
way of working but it will not just happen; it needs to be made to happen.
One of the most effective ways to improve communication is to use the right vehicle for conveying a
message at the right time. Teams communicate in many different ways such as:
• using the written word in the form of documents, emails or instant messaging
• using visualizations in the form of figures or pictures
• verbally by telephone
• verbally face-to-face (perhaps by webcam).

40 PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. PRINCE2 Agile® Foundation | Copyright© PeopleCert International Ltd. 41
Thank you for
completing the
PRINCE2 Agile®
Foundation course.
Please take a few minutes to give us your feedback
on your experiences and learning from the course
by completing the online course evaluation survey
here.

Powering
Best
Practice