1

Foreword
Present rapidly developing industries demand project management that enables quick
responses to changes. Some users of the PRINCE2® project management method
started to search for a way to incorporate agility in their projects.
This book is designed, to help you understand how you can incorporate Agile® into
your PRINCE2® projects. It provides an overview of PRINCE2 Agile®. You will probably
understand it faster if you are a PRINCE2® certified project manager or if you know the
basics of Scrum, AgilePM® Kanban or any other Agile framework, but if you do not
know any of these methods, it provides a recap of PRINCE2® and explains how the
standard PRINCE2® method could be combined in with Agile.
Some illustrations from real projects or case studies are given to aid understanding. So,
what you can learn in the book?
1. Basics of the PRINCE2® method
2. How agility can be added to PRINCE2® project
3. Project objectives in an Agile environment
4. Agilometer any Cynefin
5. Scrum and Kanban
6. Business case and value in the project
7. How an organization can be tailored
8. Agile approach to the plans
9. Which process is influenced the most
10. Requirements for training and examination

2
Content
1. Basics of the PRINCE2® method ............................................................................... 5
1.1 What is in and what is out .................................................................................... 5
1.2 Principles ............................................................................................................... 5
1.3 Project objectives ................................................................................................. 6
1.4 PRINCE2® Themes ................................................................................................. 6
1.4.1 Business Case .............................................................................................. 6
1.4.2 Organization ............................................................................................... 7
1.4.3 Quality......................................................................................................... 8
1.4.4 Plans ............................................................................................................ 9
1.4.5 Risk .............................................................................................................. 9
1.4.6 Change ...................................................................................................... 10
1.4.7 Progress .................................................................................................... 10
1.5 PRINCE2® processes............................................................................................ 10
1.5.1 Starting-up a Project................................................................................... 11
1.5.2 Directing a project .................................................................................... 11
1.5.3 Initiating a project process ....................................................................... 12
1.5.4 Controlling a stage .................................................................................... 12
1.5.5 Managing product delivery ...................................................................... 12
1.5.6 Managing a stage boundary ..................................................................... 12
1.5.7 Closing a project ....................................................................................... 13
1.6 Tailoring PRINCE2® ............................................................................................. 13
2. How agility can be added to PRINCE2® projects .................................................... 13
3. Project objectives in Agile environment ................................................................ 14
3.1 What is Fix and what is Flex ................................................................................ 15
3.2 Why the concept of FIX and FLEX was introduced? ........................................... 16
3.3 Five targets behind flexing what is delivered ..................................................... 17
4. PRINCE2 Agile® principles and behaviors ............................................................. 17
4.1 Typical agile behaviours, concepts and techniques ........................................... 20
5. Cynefin and Agilometer.......................................................................................... 20
5.1 Cynefin ................................................................................................................ 21
5.2 Agilometer ......................................................................................................... 22

3
 5.2.1 When the environment is Agile (5 on the slider) ..................................... 23
6. Vision, user stories, products ................................................................................. 24
6.1 High level product description............................................................................ 24
6.2 Products, Epics and User stories ......................................................................... 24
6.2 Prioritized product backlog................................................................................. 26
6.3 User stories and tasks ......................................................................................... 26
6.4 Prioritization and estimation .............................................................................. 27
6.4.1 Transforming requirements to User stories ............................................. 28
7. Processes ................................................................................................................ 29
7.1 Acceptance of products ...................................................................................... 30
7.2 Reporting ............................................................................................................ 30
7.3 Burn-down and Burn-up chart............................................................................ 31
7.4 Sprint velocity and work estimation ................................................................... 31
7.5 Tailoring processes ............................................................................................. 32
8. Organization ........................................................................................................... 32
8.1 The Project Board ............................................................................................... 32
8.2 The Project Manager .......................................................................................... 32
8.3 Team Manager .................................................................................................... 33
8.4 Scrum Master ...................................................................................................... 33
8.5 Product Owner .................................................................................................... 34
9. Business Case ......................................................................................................... 34
9.1 Sprint Zero .......................................................................................................... 34
9.2 Benefits and value .............................................................................................. 35
10. Plans in Agile environment ................................................................................. 35
10.1 Do we need a Project Plan? ......................................................................... 35
10.2 Team Plans ........................................................................................................ 36
10.3 Stage Plan ..................................................................................................... 36
10.4 Emergent planning ....................................................................................... 36
11. Training and certification .................................................................................... 36
a) Training ............................................................................................................... 36
b) Certification ..................................................................................................... 36
11.3 Exam ................................................................................................................. 37

4
1. Basics of the PRINCE2® method
If you are a certified and experienced PRINCE2® project manager, you do not need to
read this chapter. This chapter will review Version 5 of PRINCE2® from 2009 without
mentioning Agile methods which appear in later chapters.

1.1 What is in and what is out

PRINCE2® is a very flexible and effective method of project management. It can only
be used in project environments, despite of some Agile methods, which can also be
used in standard organization operations (sometimes called as BAU – Business As
Usual). PRINCE2® is universal, can be used in any industry (while many Agile
frameworks are dedicated to be used only in IT projects), any type of project and any
country. PRINCE2® does not contain any “soft skills”; although it recognizes, that as the
project manager, you must know about leadership, motivating people, solving
conflicts, building teams and have presentation skills. All of this is outside of PRINCE2®
and you must gain these skills in addition to the PRINCE2 or Agile method.
PRINCE2® does not teach any techniques. In fact, there are two generic techniques
explained in PRINCE2® (Product Based Planning technique and Quality Review
technique), but if you have your own techniques, you are free to use them. (PMI
defines 104 of them) and if you need to compare progress in the stage in comparison
with sources spent and delivered value (defined in EVA), you must use some external
knowledge.

1.2 Principles
PRINCE2® defines 7 principles. All of them must be applied in order to have a PRINCE2®
project.
a) Continued business justification – it might be obvious, but many projects still
define justification at the beginning, but later this justification might disappear.
It is important to check on regular basis, if the project is still viable, achievable
and desirable and therefore worthwhile investing in it.
b) Learning from experience – in fact, there is no project management standard
or system, which would not support this principle. Experience from previous
similar projects can help to significantly improve the success of the project and
the project manager must seek this experience throughout the project’s life.
c) Defined roles and responsibilities – this might seem natural but there might be
people in a project who have no idea to whom they should report, what exactly
they should do and when their obligation commences and finishes. They should
also agree with their role in the project. Clearly setting up an organizational
structure with defined roles and responsibilities of all people in the project will

5
 facilitate communication and bring better results in delivering the project
objectives
d) Manage by stages – the project cannot be managed as one big unit, but must
be split into smaller chunks. It is not worth spending the time planning in
extensive detail in advance, so it is better to split the project into shorter stages
and plan in detail only to the horizon. To satisfy this principle, the project must
have at least 2 stages; the first is initiation and the second is the management
stage.
e) Manage by exception – this is about tolerances given to the project managers.
While they manage the project within tolerance, they have full discretion to
continue. Once, there is a forecast of exceeding the tolerance limits, they must
immediately escalate the situation to the next level of management
f) Focus on products – though some project management methods concentrate
their effort first on activities, central for PRINCE2® are the products. PRINCE2®
delivers the benefits of the project via Project Product (final delivery of the
project).
g) Tailoring to the project environment – it is very natural that different projects
will have different management styles. The Project Manager is committed to
adjusting the project management method in order to increase the chances of
the project being successful

1.3 Project objectives

PRINCE2® defines 6 project objectives (or targets), which are the same as project
variables and tolerance areas. Tolerances in PRINCE2® are the permissible level of
deviation above or below what has been planned. In some literature these 6 objectives
might be also called aspects, but in Scrum or other methods, the word aspect has a
completely different meaning
During management of stage The Project Manager works of stage mainly with time and
cost tolerance, but all project targets must be controlled and managed since they might
significantly influence the success of the project.

1.4 PRINCE2® Themes

PRINCE2® themes describe areas of project management that must be addressed
continually.

1.4.1 Business Case

The Business Case theme closely relates to the Continued Business Justification
principle and its purpose is to establish the mechanism to judge whether the project is
(and remains) desirable, viable and achievable, and is the major source for the decision
about the investment at the beginning as well as during the project.

6
This theme addresses, how the initial idea or need is developed into a sound
investment proposition for the organization and how the Project Manager maintains a
focus on organization objectives through the project.
Business case should contain the following:
1. reasons to establish the project
2. business options (-do nothing, -do minimum, -do something)
3. benefits expected from the project in measurable form
4. dis-benefits, which might lower the value delivered by the project
5. cost (including the costs of the project, maintenance costs of delivered products
and source for financing the project)
6. timescale including the period when benefits will be delivered
7. investment appraisal
8. major risks, which might have an impact on delivered benefits

1.4.2 Organization
Every project must have a clear organizational structure, defined roles and
responsibilities of each person working on the project, lines of responsibilities and
reporting. The purpose of the Organization theme is to define and establish the
project’s structure of accountability and responsibility.
A Typical PRINCE2® project has 4 layers of responsibility
1. Corporate or Programme, which is commissioning the project and after project
termination, it will use the results of the project. This level sits above the project
itself.
2. Directing level - Project Board, representing the interests of business, users and
suppliers. It is responsible for the success of the project
3. Managing level - Project Manager, responsible for day-to-day management of
the project
4. Delivering level - Team Manager, responsible for the development of the
project.

PRINCE2® defines 8 basic roles:

1. Executive is ultimately accountable for the project success towards the
corporate/programme management and key decision maker (supported by the
senior user and senior supplier).
2. Senior User is responsible for specifying the needs of those who will use the
projects products. He must specify the benefits which the Project’s product

7
 (project deliverable) should deliver and is responsible that these benefits will be
reached after the project when using the product output.
3. Senior Supplier represents the interests of those, who are developing the
project´s products. He is responsible for the quality of the delivered products
and for the technical integrity of the project.
4. Project Assurance is a delegated role of the project board (Business Assurance,
Supplier Assurance or User Assurance) and is responsible for monitoring all
aspects of the project performance independently of Project Manager and also
gives the advice to Project Manager prior escalation to the project board.
5. Project Board might delegate certain responsibility to the Change Authority if it
is expected that the project is likely to face many changes. The Configuration
management strategy will define the limits of responsibility of the Change
Authority as well as the use of Change budget should it be necessary.
6. Project Manager is responsible for day-to-day management of the project. He
has the authority to run the project on behalf of the Project Board within the
constraints specified by the Project Board. He is responsible for the majority of
the PRINCE2® processes and manages the project on a stage-by-stage basis.
7. The Project Manager might be supported by the Project Support (delegated
role), which might be responsible for routine work, such as configuration
management, maintenance of registers, assistance in reporting, planning, etc.
The Role of the Project Support can be undertaken within a PMO.
8. Team Manager’s primary responsibility is to ensure the production of products
specified by the Project Manager in the form of work packages. The Team
Manager reports to the Project Manager, but in small projects this role is not
mandatory and can be undertaken by the Project Manager.

1.4.3 Quality
The purpose of the quality theme is to define and implement the means by which the
project will verify that products are fit for the purpose.
PRINCE2® defines quality as the totality of features and inherent or assigned
characteristics of a product, person, service and/or system that bear on its ability to
show that it meets expectations or satisfies stated needs, requirements or
specifications.
The quality theme also covers the implementation of continuous improvement during
the project.
Only products of the agreed quality can guarantee the delivery of benefits so it is
important to check the quality continually during the process of development of the

8
product as well as when products are delivered. PRINCE2® defines a quality review
technique which should be applied to review the quality of developed products.

1.4.4 Plans
The purpose of the Plans theme is to facilitate communication and control by defining
the means of delivering the products.
PRINCE2® defines 3 levels of plans:
1. Project Plan –a high level document which covers the whole duration of the
project. The Project plan is prepared during the Initiation process and updated
in Managing Stage boundary process. The Project plan is used by the Project
board to control overall progress.
2. A Stage Plan is a low level plan with sufficient detail to manage the project on
day-to-day basis. The Stage plan identifies when and how the project manager
authorizes and checks the work-packages, to report the development to the
Project Board and to monitor any deviations. The Stage plan is developed in the
Managing a Stage boundary process and updated regularly during the stage.
3. A Team Plan is prepared by the Team Manager as best of the acceptance of
Work package. It is used to monitor the progress of the development of
products for both Project Manager and Team Manager. A Team plan is not
mandatory.
Another plan defined by PRINCE2® is the Exception Plan, which can be at the level of
project or stage plan. The Exception plan is created, when there is forecast of tolerance
deviation and the relevant authority decides to replace the original plan by an
Exception plan.
The Product based planning technique is defined by PRINCE2® to help to create a plan.
The Product breakdown structure and Product flow diagram will help to visualize and
facilitate preparation of plans by focusing on what will be delivered

1.4.5 Risk
The purpose of the Risk Theme is to identify, assess and control uncertainty and as a
result, improve the ability of the project to succeed. Risk in PRINCE2® is a term for any
uncertain event, which might influence any of the project objectives. If the influence is
negative, this is called a threat, if the influence is positive, it is called an opportunity.
Risk Response is the action taken to reduce or eliminate the influence of the risk on the
projector to maximise relevant opportunities.
Responses for threats are: avoid, reduce, transfer, fallback, accept and share.
Responses for opportunities are share, enhance, exploit and reject.

9
 1.4.6 Change
The purpose of the change theme is to identify, assess and control any potential and
approved changes to the baseline. Since the change must be controlled to avoid “scope
creep”, configuration management must be in place to identify versions and variants
of the products.
Evaluation of the impact of a change will result in a decision being taken, a scale of
priority, severity and level of decision making authority must be defined. PRINCE2®
recommends using MoSCoW, which might be defined as following:

Prioritisation Severity / Decision Authority

- e.g. MoSCoW scale - e.g. Alphanumeric/Description

Must have 4. Critical Corporate/Programme

Should have 3. Major Project Board

Could have 2. Significant Change Authority

Won’t have (for now) 1. Minor Project Manager

Table 1: MOSCOW Prioritization

1.4.7 Progress
The purpose of the Progress Theme is to establish a mechanism to monitor and
compare actual achievements against those planned, provide a forecast for the project
objectives and the project continual viability and viability of plans. The Progress theme
explains, how tolerances might be set up and which authority is authorized to make a
decision if the tolerance is forecast to be exceeded set levels.

1.5 PRINCE2® processes

The process is structured set of activities designed to accomplish a specific objective.
It takes one or more inputs and turns them into outputs. PRINCE2® defines 7 processes.
The processes represent the journey through the project.

10
Figure 1: PRINCE2 Process Diagram

1.5.1 Starting-up a Project

Starting up a Project is a pre-project process, where someone’s idea or need is
considered. It is trigged by the Project mandate, which is provided by commissioning
organization, (Corporate or Programme).
The main task to Starting up the Project Process is to evaluate the viability of the
project based on high level data to avoid wasting money on initiating badly prepared
ideas. The Project Manager prepares high level documents including Outline Business
Case and Organization Structure. It defines main delivery of the project, for the Project
Product Description, identifies the project approach and prepares the stage plan for
the initiation stage. The Project Brief incorporates most information collected during
Starting up a Project.

1.5.2 Directing a project

Directing a project is a high level decision making process where the main task is to
judge the viability of the project. They need to make the decisions at all key points. The
natural decision making points are stage boundaries, but also any time during the
project, when major risk or issues arise or there is a forecast to exceed stage
tolerances. This situation is called an exception. Directing a project process might also
provide ad hoc direction any time, when a decision is needed. The main activities of
Directing a project are Authorizing Initiation, Authorizing the Project, Authorizing Stage
or Exception Plan and Authorizing Project Closure.

11
 1.5.3 Initiating a project process
The main task of this process is to prepare solid foundations for the project. Only the
management products are prepared and they are grouped into a Project Initiation
Documentation (PID). These are project-level managements products, based on which
the Project board must make a decision about the funding of the project. The PID
contains 4 strategies (Risk Management strategy, Configuration Management strategy,
Quality management strategy and Communication management strategy). PID also
contains the high level Project plan, project controls describing how much the Project
Board needs to control the Project Manager (stage boundaries, tolerances, format and
frequency of communication, roles description). The Outline Business Case is refined
and as a part of the PID gives full information about viability of the investment
identifying that benefits will outweigh the costs and risks.

1.5.4 Controlling a stage

This process is done by the Project Manager. The main activity is the authorization of
Work packages to the Team Managers, controlling the ongoing work (product
development) via Checkpoint reports and accepting completed Works packages after
the quality has been reviewed and the product is approved.
The Project Manager must also review the stage status to see whether there is a
deviation from the stage plan, if any tolerances are forecast to exceed the approved
limits or if issues or risks appeared (or changed their status). The Project Manager
usually reviews the stage status on a periodical basis and produces a Highlight Report,
which informs the Project Board about the actual status of the stage.

1.5.5 Managing product delivery

This is the process in which a Team Manager accepts the Work package, develops the
product or service defined in the Work package, checks the quality of products and
regularly informs the Project Manager about the current status of the Work Package
in the form of Checkpoint Reports.
When the product is developed, it must be quality reviewed using the Quality Review
technique (or any other agreed techniques) and approved. After gaining the approval,
the Team manager delivers back the Work package to Project Manager.

1.5.6 Managing a stage boundary

The Project Manager can only continue the work in the next stage, if the Project Board
authorises progress. The process in which all the documentation is prepared is called
Managing a Stage Boundary. This process formally evaluates the current stage (End
stage report is created), plans the work in the next stage and updates the Project Plan,
Business Case and if necessary other documents incorporated in the PID.

12
Similar activities are done when an exception occurs and the Project Board asks the
Project Manager to prepare the Exception Plan.
Only when next Stage Plan or Exception Plan is authorized, The Project Manager will
receive resources allocated to manage the next stage.

1.5.7 Closing a project

A PRINCE2® project can only be closed when Project Board decides to do so. In order
to make this decision, The Project Manager must trigger Closing a Project process. The
main task of the Project Manager is to gain the final acceptance from the customer (or
partial acceptance if prematurely closed). They must also evaluate the project (prepare
an End Project Report), check if any products are still under development, close all the
documents, archive them, identify any follow on actions and ask the Project Board to
officially authorize the project closure.

1.6 Tailoring PRINCE2®

Since every project is different, with a different project team, project environment,
industry, culture, country etc. the project management must always be tailored so that
it is the best fit for the conditions. The project management not only leads to successful
projects, but also needs to be effective. Everything in PRINCE2® can be tailored except
the Principles. Tailoring does not mean to omit elements of PRINCE2 but is about
grouping them together or amending them for a better fit to the project.
And this is also the way, you can adapt PRINCE2® to an agile environment….

2. How agility can be added to PRINCE2® projects

There is not a button in PRINCE2® switching it to agile. As mentioned in the previous
chapter, the basic component of PRINCE2® is tailoring and this is, how agility can be
added into a PRINCE2® project. It is not about change PRINCE2® to an agile method,
but it is about how much agility can be added to the project. Moreover, this added
agility is not the same in the project. If we consider the processes, most agility can be
added to Managing Project Delivery. When we consider the levels of management, less
agility can be added on directing level, but significant agility can be added to managing
level and delivering level can be agile in majority of actions and procedures.
The most important part of “agiling” PRINCE2® is the creation of an agile project
environment. Again, it does not need to be a 100% agile environment at all levels. (See
the Agilometer).
To explain this, for example, if the Project Board does not accept, that the Project
manager or teams should work in an agile way, this project cannot be successful. Being

13
agile usually means, giving trust to people and any teams at the lowest level – the
developer or creators but also upper levels of management must accept agile
principles of working.
When considering, how to add agility into PRINCE2®, the authors were inspired mainly
by Scrum and Kanban. In fact, Kanban does not define any roles in the project, while
Scrum defines only 3 core roles, one of which Scrum team (or development team).
None of the roles is superior or subordinated to the other and the team as unit (not
individuals) are independent and collectively responsible for the success of the project.
Agile methods recognize the people as the main focus in the project, while PRINCE2®
does not define the roles below the Team Manager level.
As part of recognizing people, the Project Board (and even– corporate or programme)
must recognize, that they might not get everything they want. Accepting these 2 facts
gives the basics for PRINCE2®.
Taking this into account, agility must be incorporated the in Project Vision. This is a
new term in PRINCE2 Agile® projects and to a certain extent it is similar to Project
Product Description or in the wider sense in the Project Brief. The Project Vision relates
to the Business Case. Unlike in the majority of waterfall (e.g. PMI) and agile (e.g. Scrum)
the methods preparation of Business Case is outside the project scope (it means, that
the Business Case exists when project starts), the trigger for a PRINCE2® project is the
Project Mandate and the outline Business Case is prepared as part of the Pre-project
activities (if not provided in Mandate).
Agile projects must also have Business Case and the Agile Project Vision. It should be
vague enough to be able to be modified in the later stages of the Project, but exact
enough to serve as the document on to which base investment decisions. The Project
Vision and Business Case should be high level documents enabling some modification
without changing the baselines.

3. Project objectives in Agile environment

Prioritisation is central to an Agile approval. The most common prioritization technique
is MoSCoW. The customer must get all the MUSTs (without anyone of them, the
project will not meet its objectives– for example an e-Shop MUST have at least one
option for on-line payment), will get some SHOULDs (an e-Shop should have more than
one payment options) COULD have the button to recommend product to a friend and
WON’t have the alternative delivery address if shopper is not at home when the courier
delivers the products.
Project objectives in an Agile environment (or constrains) for time, cost, quality, risk,
scope and benefits does not mean, that they can be changed depending how the

14
project develops. An Agile project is expected to deliver value even early in the project
and the customer must know what they will get, when and how much it will cost.
PRINCE2 Agile® introduces the concept of flexibility (FLEX) of certain components and
fixing (FIX) some others. The Customer must understand, that some features may need
to be dropped but they will receive value.

3.1 What is Fix and what is Flex

Time - FIX There is zero tolerance for extra time to deliver the Project Plan.
Considering negative tolerance (the project should finish sooner) is
not relevant, because the project should deliver SHOULD or COULD
components in the remaining time
Cost - FIX The project cannot exceed the agreed budget. Again, if major
components are delivered at lower cost, the remaining budget can be
used to deliver SHOULD and COULD have components
Table 2: FIX and Flex component - Part 1

As you can see, in the area of time and costs, PRINCE2® Agile® is stricter than PRINCE2®,
which provides a Project Plan which can have tolerances on time and cost given by
corporate/programme.
Quality FIX The level of quality is protected, but it is clear, that not all quality
and FLEX criteria (products) and acceptance criteria (project product) are of
equal importance for the customer, so they can be prioritized. It is
necessary to fix essential customer quality expectations, while FLEX-
ing those acceptance criteria, which are desirable.
Scope – FIX Not everything, which the project will create is of equal importance
and FLEX to the customer. There is zero tolerance (FIX) for essential products/
features but other products, which are of lower priority might not be
delivered.
Risk - FIX or Tolerance to be defined according to the needs of the Project Board
FLEX and Project Manager as this depends on the specific situation.
Benefit - FIX Zero tolerance for the level that is defined as “minimum viability” in
or FLEX the Business case. Tolerance might be used above “minimum
viability” to add extra benefits.
Table 3: FIX and Flex component - Part 2

15
Figure 2: FIX and Flex component

3.2 Why the concept of FIX and FLEX was introduced?

This is driven mainly by fast technology development and shortening of time to market.
It may be less important to have a product of highest quality, but is more important to
have it quickly. (This eBook certainly will not be perfect in the first issue but brings you
value).

Example:
Imagine the mobile phone developer. If it is developed using the “classic” management
method, so probably pre- development will last about 6 months when all the features
are described in detail. Then developers spend 2 years developing all the features and
afterwards, 6 months testifying final acceptance. Finally the mobile phone will fulfil all
the customer quality expectation and pass the acceptance criteria. So will this project
deliver benefits? NO! Would you buy a mobile phone with functionality defined 3 years
ago? In an agile environment, the customer defines only basic requirements, like the
size of the screen, battery duration, Wi-Fi, GPS etc. But others might be defined later
during development, some of them even shortly before launch.

16
3.3 Five targets behind flexing what is delivered
There are 5 targets to further explain the concept of fixing and flexing.

Target Explanation
1 Be on time and hit Being on time and hitting deadlines has many very
deadlines significant advantages.
2 Protect the level of Ensuring that the level of quality is protected and
quality regarded as vital is of paramount importance to a
project. This will lead to a lower cost of ownership
through the lifetime of the final product.
3 Embrace change Embracing change by seeing it not only as
inevitable but also as a positive influence on a
project allows for a more accurate final product.
4 Keep the team stable and Keeping team stable over the short term removes
do not add people to a the temptation to add people to a team in order to
team to try to deliver catch up with work when in reality it is more likely
faster to have little or no effect
5 Accept that the customer Accepting the premise that not everything defined
does not need everything in the initial stage of a project must be delivered is
wise. It inevitably turns out that somethings do not
add enough value to warrant delaying the project
because of them.
Table 4: 5 project targets

4. PRINCE2 Agile® principles and behaviors

In order to explain PRINCE2 Agile® principles and behaviours we should briefly describe
the Agile approach to project management in general.
According to Highsmith (2002) “Agility is the ability to both create and respond to
change in order to profit in a turbulent business environment. Agility is the ability to
balance flexibility and stability."
The IT Industry has been the main driver to create an agile system of product software
development. That is why the majority of agile frameworks and techniques originated
to manage software development projects.
Fowler and Highsmith (2001).created the “Agile manifesto”
“We are uncovering better ways of developing software by doing it and helping others
do it. Through this work, we have come to value the following:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation

17
  Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left
more.”

There are 12 general agile principles, which originate from different agile
frameworks:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the
project
5. Build projects around motivated individuals. Give them the environment and
support their needs, and trust them to get the job done
6. The most efficient and effective method of conveying information to and within
a development team—such as a Scrum Team—is face-to-face conversation.
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances Agility.
10. Simplicity—the art of maximizing the amount of work NOT done—is essential.
11. The best architectures, requirements and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective and
then tunes and adjusts its behaviour accordingly.
On top of these general principles, each agile framework defines another principle,
which most characterizes the work in the project.
Since PRINCE2® principles are defined and are valid also in an agile environment,
PRINCE2 Agile®M defines 5 behaviours, which bring agility into a PRINCE2® project.
1. Transparency – the most important elements of this principle come in the form
of the common agile values of honesty, trust, integrity and respect.
Transparency is not just visibility understood by putting information onto a
Progress board (or Kanban board), it is more about revealing and sharing
information to everyone, which might be good, as well as bad.

18
2. Collaboration – is more than just cooperation. Empowered, self-motivated
teams work as one unit. Collaboration is about sharing the problems and making
common approaches to finding the solution. Collaboration does not mean only
internal within the team. It is also external mainly with stakeholders, users and
business representatives, to make all of them responsible for the success of the
project.
3. Rich communication – is much more, than just sending reports to the next level
of management. Rich communication is more about face-to-face
communication (if teams are not collocated in one place, then using some high
tech communication channels if possible with video-camera). It is generally
accepted, that more than 70% of communication is non-verbal so the advantage
of face-to-face communication is in fast and correct understanding. The
strongest tools and techniques of rich communication are daily-stand-ups,
planning, reviews and retrospective meetings.
4. Self-organization – means trusting the team to organize the work, since they
know best how to get the job done. If plans must be created, then invite team
members to help doing so. The more they feel, that it is “their plan” the more
the plan will be followed. Self organizing creates mutual respect. Therefore, the
Project Manager should leave a Team Manager to focus on product delivery and
they will do it better if they feel trusted. (Find the relations between the Project
Manager, Team Manager, Scrum Master and teams in chapter 8).
5. Exploration – is about learning and feedback. In order to create the right thing
it is necessary first to know, what the right thing is. Learning helps to improve
the products. It is usually by using experiments, prototypes, spikes help to
understand the customer expectations, get quick feedback and reduce the
impact of mistakes. The faster, better feedback the team gets, the quicker
progress can be made. The sooner the team solves “known unknows” and
uncovers “unknow unknows” the sooner they can arrive at the right destination.

19
Figure 3: Agile project Behaviours

4.1 Typical agile behaviours, concepts and techniques

Term Examples Similar term
Behaviours Being collaborative, self organizing, Principles, values and
customer focused, empowered, mind-set
trusting not blaming
Concepts Prioritizing what is delivered, working
iteratively and incrementally, not Fundamentals
delivering everything, time focused,
inspect and adapt, limiting work in
progress
Techniques Burn chart, user stories, Practices, tools
retrospectives, time-boxing,
measuring flow
Table 5: Agile behaviours, concepts and techniques

5. Cynefin and Agilometer

Before the project manager starts the project, they must understand how complex the
environment is and which risks exist implementing an agile approach.

20
5.1 Cynefin
To measure the level of complexity – the Cynefin framework was created by David
Snowden. It is decision making framework that has been designed to help with
understanding and determining what level of complexity exists in given situation or
environment.
There are 5 defined relationships:
Obvious – where the relationship is obvious and is usually addressed by “best practice”
Complicated – where some form of analyses or expertise is required to understand the
relationship, which is usually addressed by “good practice” but where there might be
several options available.
Complex – where the relationship can only be understood in retrospect and is
addressed by “emergent practice” which may evolve to a new way of working
Chaotic – where there is no apparent relationship and any way of working is described
as novel
Disorder – where the relationship is unknown

Figure 4: Cynefin

21
5.2 Agilometer
The task of the Agilometer is to best estimate different areas of risk when applying
agile project management. Every project situation is different in some form due to
factors such as the level of trust between the customer and supplier, the technology
being used or level of uncertainty.
In order to receive the most benefit from using a method or approach it is essential to
adjust and adapt it to suit the context and conditions in which it is operating.
For PRINCE2® to be tailored in the most suitable way it is important to assess the
context that a project exists with regard to the environment and the working
relationships. To achieve this, PRINCE2 Agile® has an assessment tool called Agilometer
to answer the question “How Agile can we be on this project”?
The Agilometer looks at 6 key areas and the Project Manager is responsible for
canvassing the key stakeholders involved in the project as to what values to give each
category. Each category is represented on the figure by a slider.

Figure 5: Agilometer

The experience of the Project Manager will dictate, how each slider is set and the
situation evaluated. It is not possible to make any kind of “average” agility and each
area must be considered in isolation.

22
5.2.1 When the environment is Agile (5 on the slider)
1. Flexibility of what is delivered
Customers understand that not everything is going to be delivered; that changes
might appear and these changes should be incorporated into the project. The
Customer is familiar with a prioritization technique (e.g. MoSCoW) and is willing
to participate actively to prioritize products or features.
2. Level of collaboration
The team is “set-up”, produced excellent results in the past, there are not
“unresolved” conflicts, team members accept positive critique and accept that
they make mistakes, people work quickly, effectively and help each other, they
are used to working in a partnership environment between the customer and
supplier
3. Ease of communication
Communication is informal and easy among all parties involved, people are used
to face-to-face communication, used to working with prototypes and models.
There is a high level of visibility of progress, plans and results (mainly via a
progress board, issue and risk logs), people are collocated or at least a high level
of visual communication technology is introduced. Formal communication and
reporting is limited.
4. Ability to work iteratively and deliver incrementally
Benefits to the customers should be delivered in partial deliveries, work is done
iteratively and refined in the later stages, there is experimenting and exploring
and failures present significant learning and improvement options. Everybody
understands, that the thing might not be perfect the first time, incremental
delivery brings quick and frequent feedback which increases the deliverability
and benefits to the customer.
5. Advantageous environmental conditions
The overall working environment is very supportive of working in an Agile way.
People are assigned full time working on the project, they have appropriate
skills, teams are stable and experienced. Any external parties are comfortable
working in an Agile way, Agile tools are used and commercial and contractual
environment is favourable to an Agile way of working.
6. Acceptance of Agile
All stakeholders involved in the project are fully aware of the behaviours,
concepts and techniques of working in an Agile way and they fully understand
the advantages which an Agile way of work brings. Peripheral stakeholders are
also aware of the need to carry out their roles in an “Agile friendly way”. People
are trained in the appropriate approach and there are no blockers to using Agile
work.

23
6. Vision, user stories, products
PRINCE2® and Agile in general use different vocabulary, though there are usually
similarities in what is described.

6.1 High level product description

PRINCE2® uses the term “Project Product”, which is the main delivery of the project,
including Customer Quality expectations and Quality criteria.
Agile frameworks usually use the term “Product Vision” (or in certain circumstances
“Project Vision”). The format might be following:
For: «target customer»
Who: «needs»
The: «product name»
Is a: «product category»
That: «product benefit. Reason to buy»
Unlike: «competitors»
Our product: «differentiation or value proposition»
This is a high level description of project delivery, which answers what the customer
needs and why it is needed unlike the “Project Product Description”, The Product
Vision does not contain any quality or acceptance criteria, but it doesn’t mean, that it
cannot contain them. If, they are included they should be vague enough to give the
Project Manager flexibility in prioritizing, what is delivered.

6.2 Products, Epics and User stories

Low level deliverables in PRINCE2® are called products – in this case “Specialists
products” (there are also management products such as plans, reports, strategies and
specialist products delivered by the development teams). The work in PRINCE2® is
assigned in the form of Work Packages to Team Managers. The Work Package might
contain 1 or more products. Products are usually at a low level of granularity and are
not split into parts by a Project Manager but are delivered as a unit. The process of
splitting Project Product into products is called “Product Breakdown Structure”. The
products in between are called “major products”. Plans in PRINCE2® contain the
information about, which products should be manufactured, when, by whom, at what
cost etc. The Quality of each developed product is measured prior its delivery (Quality
Review technique can be used).

24
An Agile way of working splits the Product Vision into Epics and User Stories. (Epics are
large User Stories, which cannot be delivered in 1 sprint, but must be further split into
User Stories). A User Story is a lucid form, in which any requirement is presented.
The typical format for a User Story is:
As a <type of user>,
I want <to perform some task>
so that I can <achieve some goal/benefit/value>
So User Stories have the perspective of how the user, system administrator, developer
etc. see the benefits, rather than detailed specification.

Example:
MobiParts – a Shopper sells spare parts for mobile phones to different services and
wants to extend sales to end users.
Product vison:
For: «MobiParts»
Who: «need to sell products to end users and enlarge the market»
The: «web page will be created»
Is a: «an e-shop»
That: «enables any users to search, order, buy, evaluate and communicate about spare
parts»
Unlike: «Chinese sellers»
Our product: «will have a much wider offer, detailed descriptions, standard 2 year
warranty, national delivery and a helpdesk option»
Example of Epics:
As a buyer, I want to have the facility to pay online, so that I can quickly purchase any product.
As a website administrator, I want to have statistics about all visitors and buyers so
that I can flexibly change my marketing strategy.
As a web administrator, I want to see, how many products were bought in a certain
period, so I can track the stock.
Use stories:
As a buyer, I want to pay using PayPal, so I can revoke my purchase, if I am not satisfied.
As a web administrator, I want to see how many product were bought in certain period
so I can fill the stock.

25
It must be realized, that there are functional and non-functional requirements (user
stories.) Functional describe what user story does, non-functional how well it is done.
User stories therefore should be created not only by the customer, but also in close
cooperation with the development team.

6.2 Prioritized product backlog

It is not necessary to split all Epics into User Stories at the beginning of the project. It
is not even necessary to define all User Stories, since some of them can be omitted or
even some of them will come later in the process.
In any case, all of them must be prioritized, so the team knows, which of them provide
the greatest value to the customer, and so which of them should be manufactured first.
In Scrum, the Product Owner (assisted by the Scrum Master and the Team), is
responsible for prioritizing the Product backlog. This concept has all responsibility for
the customer view focused on one person. Therefore the responsibility for
prioritization should be from a wider stakeholder representative, since they might
bring new points of view, skills and knowledge.
The Product backlog is not only prioritized at the beginning, but it is a continued
periodical process as some items are delivered and new items might be added than
priorities might be changed.
When taking into account project risks and their influence on the product backlog (the
bigger risk, the higher priority), a Risk prioritized product backlogs list is produced.

6.3 User stories and tasks

The Development team commit to some user stories at the beginning of sprint, which are
further prioritized, estimated and split into tasks. This is the task of the development team
with the assistance of other stakeholders, such as the Project Manager, stakeholders etc.
Once the development team commits to work on specific user stories during the sprints, no-
one external should influence their work. The only exception is a situation where significant
change appears and there is no longer any sense to continuing work on these user stories and
the sprint should be prematurely closed.
Example of Task:
User story:
As a buyer, I want to pay using PayPal, so I can revoke my purchase, if I am not
satisfied.
Tasks:
1. Find the recent PayPal API (Web services)
2. Create test account
3. Test the payment on the test account
4. Set up the real account
5. Test the payment on the real account

26
6.4 Prioritization and estimation
As previously mentioned, requirements and relevant user stories must be prioritized
once they are placed on the product backlog. One of the most popular prioritization
method is MoSCoW. It represents the acronym for Must have, Should have, Could Have
and Won´t have for now. When prioritizing requirements we only need to answer the
question; how important is it?
Must - means that without delivering this requirement the project would not deliver
any value or meet the Business Case or Product Vision.
Should –an important feature, but the final product can deliver value without it,
although it would be costly or take a long time to add the feature later.
Could – less important feature and probably majority of customers will not need it. It
would be an easier or less costly to include in a future release.
Won´t have for now – users can easily cope without it or it is not required to deliver
Product Vision.
Example:
What should our website contain?
Product descriptions with MUST – product description
images SHOULD – images (buyer can probably buy
the product from the description. Many
products do not have images)
Ordering or putting in to MUST – it is the only way to buy something
the Shopping cart

Editing the shopping cart SHOULD – if a buyer cannot edit the shopping
cart, he can delete it and put the item in
again
Different ways of MUST – for one type of payment
payment SHOULD – for more ways of payment
COULD – payment on delivery
WON´T HAVE – sending a check to shop
Setting delivery address MUST – it is the only way to deliver the order
to the customer
COULD – personal pick up from the shop
Facebook “like” button WON´T HAVE – it is of very low priority
Review the product COULD – people might find reviews on other
websites
Creating a profile MUST/COULD – depending on the customer
preference. Some buyers might buy the
product without creating a profile

27
Though MoSCoW is probably the most common prioritization technique, but there are
many others used in agile projects such as:
- 100 point method – customers get 100 points and vote for the features that
they feel are most important
- Monopoly money – customer gets “false money” and must decide, how much
they are willing to pay for each user story
- Kano analyses – used mainly when new products are being produced
- Relative prioritization – comparing 2 user stories and deciding, which of them
is more important
Estimation is used primarily by the development team to get an idea, of the difficulties
of each user story, and when the user story is split into tasks, how much effort each
task will require
The Following estimation techniques are described in Scrum:
- Planning poker – usually requires consensus of team members. Each team
member gets cards numbered in sequence (e.g. 1,2,3,5,8,13,21..) and estimates
the difficulties of each task.
- First of Five – it is a voting technique by showing fingers. 1 finger means
disagreement with the group conclusion and 5 fingers means agreement with
the group conclusion. Fingers 2-4 mean, I do not fully agree/disagree and I am
ready for discussion
- Relative sizing/Story points – the team will estimate, which story is relatively
simple and this story “costs” 1 point. Other stories are judged relative to the
first story. The result might be for example “5”, which means that this story is 5
times more difficult than the first story.
- Wideband Delphi – this is also well-known techniques. It is a group-based
technique, but all members of the group make anonymous estimates.

6.4.1 Transforming requirements to User stories

It is not easy to write good user stories. “INVEST” mnemonic can help. The meaning
for different letters represent:
I Independent The user story should be self-contained, in a way that there is no
inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be
changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimable You must always be able to estimate the size of a user story.

28
S Small User stories should not be so big as to become impossible to
plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the
necessary information to make test development possible.

7. Processes
Standard PRINCE2® processes are described in chapter 1.5. Now, we need to
understand, how they can fit into agile environment.
In Agile working, there is no need for very much upfront planning and the project
documentation does not need to be very detailed. This seems to be useful to tailor ing
a project to combine the Starting Up and Initiation processes. (This tailoring also
applies to standard PRINCE2® projects that are small or mandatory projects, where
decisions about continuation of the project after Starting up is not relevant and wastes
time, as the project must continue anyway.)

Figure 6: 3 levels of project management

As shown in the figure, agility is most reflected at the Product Delivery level, less at
Project Management level and probably least at Directing. It does not mean, that
development teams work Agile, and Project Board works as standard PRINCE2®. It
means, that the Project Manager and the Project Board members do not need to have
as deep on agile understanding and do not need to make all the decisions purely in an
Agile way, though low agility here (see Agilometer 5.2) might cause risk for the project.

29
Figure 7: Agility in Managing product delivery process

The most important differences from standard PRINCE2® are seen in the Managing
Product Delivery process. They are mainly in understanding Time-boxing and how
teams must be stable. One or more teams will work together. They will accept the
Work-Packages at the beginning of the stage and split the work into sprints. Each sprint
might deliver a potentially shippable product (a product, which should be accepted by
the customer and which brings him value). It is called a “release”. Not every sprint
must finish with a release to the customer.
Work Package is split into sprints. In Scrum, the length of a sprint is fixed, in Kanban it
is a flow, which is fixed. When a team delivers everything defined in the Work Package,
they can accept another Work-Package.

7.1 Acceptance of products

A standard PRINCE2® Work-Package contains the quality criteria for each product,
while in Agile a User Story usually contains acceptance criteria defined by the customer
(Product Owner). Scrum also defines “Done Criteria”, which are the same for each
sprint or project. (For example all websites must meet the disability standards.)
Acceptance of a User Story is done by the Product Owner (representative of customer
in a general sense) after each sprint. When the product or release is accepted by the
Customer, the team accepts new tasks from the Project Manager. User Stories should
be either accepted or refused. If a User Story is refused by the Product Owner, it goes
back to the prioritized product backlog and will be worked on in later sprint.

7.2 Reporting
Controlling a Stage and Managing Product Delivery processes require preparation of
periodical reports. Since the project works in “rich communication”, this can be
achieved by the presence of the Project Manager at daily stand-ups, Sprint review

30
meetings and Sprint retrospect meetings. In a similar way a Project Manager might
report face to face to the Project Board.
It is probable, that the End Stage Report and End Project Report, though Agile, will have
a written format, but probably less detailed than in PRINCE2®.

7.3 Burn-down and Burn-up chart

Figure 8: Burn-Down and Burn-Up chart

A Burndown chart is typically used in Scrum, which reflects the Time-boxing principle.
At the beginning of the sprint, the Scrum team commits certain User Stories which
should be finished in this sprint. As time goes, fewer and fewer user stories need to be
worked on. Ideally at the end of a sprint, no user stories remain in backlog. “NO user
stories can be added to the team during the sprint”.
A Burn-up chart might be used by other Agile methods, where the number of user
stories is not fixed and new User Stories might be added or taken away from a Sprint
backlog. The line in figure shows the total number of user stories in a given time.

7.4 Sprint velocity and work estimation

Before the team commits to the user stories, they must know the “team velocity”,
which is the amount of work able to be done during the sprint. A Simple measurement
of the number of user stories typically done during a sprint might not be accurate, as a
forecast since each user story might need different amounts of effort. This is why
teams split user stories into tasks, which might be much easier to compare. Therefore
Burn-down charts might not show user stories, but the tasks at the sprint level.

31
If the work progress is measured at the level of stage or project, there might also be a
Stage or Project Burn-up chart, which will show progress during the stage or a project.

7.5 Tailoring processes

PRINCE2 Agile® processes can be tailored, they can be grouped (as mentioned at the
beginning of this chapter – grouping Starting Up and Initiating). The only constraint is
that all PRINCE2® principles must be followed, especially the principles Manage by
Stages and Manage by Exception.

8. Organization
PRINCE2® defines 8 project management team roles although 4 of them are not
mandatory. This huge flexibility will be also used in Agile projects, but some other roles
will be added.
The most significant change is the introduction of project development teams as a part
of the project and possibly the other Scum core roles of Product Owner and Scrum
Master. These roles are working in the Managing Product Delivery process, which is
the “most Agile” process in PRINCE2®, while other mandatory roles can be “less Agile”.

8.1 The Project Board

As described in the previous chapters and as stated in the PRINCE2 Agile® Targets
(accept that the customer does not need everything), the Project Board members in
particular Senior User/s must understand:
- the Fixing and Flexing concept
- the idea of prioritization and how it is implemented in the project
- and accept that the initial Project Product Description (or Product Vision) will be
vague to a certain extent,
- that non-baselined products should be changed without their authorization,
- that if a stage does not deliver everything which was planned, it is not a failure
- that customer MUST regularly interface with the development team
- that the project documentation will be less strict
- that majority of reporting and communication will be done orally or visually

8.2 The Project Manager

The Project Manager is not a preferred role in agile projects and some Agile methods
do not recognize it. An Agile Team prefers to be led and coached and not managed or
directed. Nevertheless, in PRINCE2 Agile® this role is mandatory, but must adopt
certain level of agile behaviour, mainly servant leadership. First of all, the Project
manager must accept, that development teams and team members form the most
significant part of the project and that they are self-directed and self-motivated. Their

32
work is still authorized in the form of Work packages, but their content should be
discussed and agreed with the team.
The Project Manager remains an intermediary between the Project Board and
development team and will have significant responsibility for planning, monitoring the
progress and managing the project.

8.3 Team Manager

The Team Manger role is not mandatory in PRINCE2® and in PRINCE2 Agile® but the
reasons might be different. In a small PRINCE2® project, the Project Manager can
manage the team, so there is not a need for an intermediary. In PRINCE2 Agile® this
can also be the case, but because the teams are self-organized and self-motivated.
The role of Team Leader in addition is present in DSDM Agile.
Project Manager vs. Project Team
In general there are 3 options for the how Project Manager can deal with the
development team:
a) Leave the team roles as they are, it means, that no-one is the leader and the
Project Manager might communicate with more than 1 person in the team and the
Development Team as unit is responsible for doing the work
b) There is one person from the team responsible for the communication with the
Project Manager. It might be anyone in the Development Team or even Scrum
Master.
c) There is a Team Manager or Team Leader role responsible for communication
with the Project Manager. This is best achieved, if the Team Manager is highly
collaborative and facilitates the self-organization of the team. In this case, the Team
Manager is accountable for the result of the team, but may not be working in the
development team or directly creating the products.

8.4 Scrum Master

As the name suggests, this is a typical team role in Scrum. They are primarily
responsible for ensuring that the team has a productive work environment by guarding
the team from external influences, removing any obstacles and enforcing Scrum
principles, aspects and processes. Their role is very different from the role of Project
Manager. The similarity is at the coordination level; if there are more development
teams in the project, where the Scrum master can participate at Scrum of Scrums
meetings (if they exist) or Project Manager can take this responsibility.

33
8.5 Product Owner
This role is characterized as the voice of the customers, it represents the interests of
customers in the team. One of the bottlenecks recognized by PRINCE2 Agile® is that
one person is probably insufficient to represent different customers’ requirements.
PRINCE2 Agile® recommends the wider representation of customers in the
development teams. The Product Owners main responsibility is to prioritize the
Product backlog, define acceptance and done criteria and accept user stories at the
end of sprint.

PRINCE2 Agile® does not dictate how the project team should be structured. The only
requirement is, that the Project Manager must be defined according to PRINCE2® and
self directed and self motivated team being in place according to Agile.
The role of Team Leader might be taken by an independent person or by the team. The
role of Scrum Master does not need to be an independent person, but might be filled
by the Project Manager or the Team Manager and the role of Product Owner might by
fulfilled by the customer representative in the team, quality assurance or another
stakeholder.

9. Business Case
In the majority of project management methods and frameworks the existence of a
Business Case is imperative to start the project. PRINCE2 Agile® prepares the Business
Case during pre-project work. The trigger is the Mandate, which is usually a result of
some problem, need or opportunity.
In an Agile environment, the Business Case does not need to be very formal but in
PRINCE2 Agile®, it must demonstrate the viability of the project (during the life of the
project) and provide the basis of the decision to continue the project or not.

9.1 Sprint Zero

It is usually the case in Agile, that Product Vision based on a Business Case is prepared.
Sometimes, if the vision is not clear or hard to define, a sprint zero can be organized,
which does not develop a specialist product, but it delivers a clear Product Vision,
might define features etc. This also relates to the term “Minimum viable product”,
which is about understanding the customer need and quickly getting feedback in order
to define the project.
In some situations, the Business Case should be described as best-case and worst-case
scenarios, which relate to the number of features that are planned to be delivered.

34
There is also a direct linkage to prioritization and the worst case scenario would only
deliver all the “Musts”. Naturally the expectations, that the real outcome of the project
would be as close as possible the best-case scenario.

9.2 Benefits and value

PRINCE2® defines the benefits, which the project should deliver to the customer and
the benefits are likely to be delivered after the project. Instead of benefits, Agile is
more oriented to delivering value and this value should be delivered as soon as
possible. The term benefit and value might not be interchangeable in a project context,
nevertheless, there is a direct relationships between them and when we evaluate the
project, we should consider both.
The objective of Agile projects is to deliver value as soon as possible and this is enabled
by prioritization of the product backlog (prioritization of user stories). But this does not
necessarily mean, that teams will start working on highest value requirements first.

Example:
A Customer needs an e-shop and for him the highest value would be the user stories
where a buyer can choose the product and pay for it. But developers must first create
the database, set up a web page, feed the database with products, implement security
measures etc. These requirements do not bring direct value to the customer but
without them it is not possible to deliver value to the customer.

10. Plans in Agile environment

The Agile manifesto states:… “Responding to change over following a plan”, but it does
not mean, that PRINCE2 Agile® does not need a plan. The plans might have a different
format and different use, than those known in PRINCE2®.
PRINCE2® recognize 3 levels of plans. Project Plan, Stage Plan and Team Plan and all of
them have the same structure, though the planning period and granularity are
different. It is clear, that in an Agile environment plans might have a different use and
format and they should be less Agile at high level and more Agile at a low level of plan.

10.1 Do we need a Project Plan?

The Project Plan sets out the project and with the Business Case enables the Project
Board to authorize the project. It provides a baseline, against which the project should
be measured and also states, when the customer should expect delivery of features. In
an Agile environment the Project Plans should be replaced by the Release Plan. In
PRINCE2 Agile® Release Plans would probably be insufficient to control the project,

35
since they do not contain the “costs” and therefore it is difficult to compare actual
development cost against the plan.

10.2 Team Plans

An Agile environment does not require much upfront planning. Scrum defines the
Sprint (2-4 weeks duration) and only at the beginning of the Sprint does the team
agree, on which user stories will be worked. A similar situation exist in Kanban, where
the Sprint does not need to be Time-boxed, but the “flow” is fixed.

10.3 Stage Plan

Even if a plan does not exist on the team level, the Project Manager should have a
baseline, against which they will control progress. An Agile Stage Plan has time and
cost (can Flex requirements, features, releases and value delivered to the customer
with line and cost being fixed for the project).

10.4 Emergent planning

Emergent planning is empirical and tends to plan as late as possible (avoiding huge
upfront planning) and the plans are more detailed only when the granularity is needed.
The plans are also adjusted as the project develops and must provide room for
changes.

11. Training and certification

PRINCE2 Agile® was (launched in May 2015) and is expected to be adopted by many
individuals and organisations.

a) Training
A number of Accredited Training Organisations provide PRINCE2 Agile® training, using
classroom, virtual classroom, or e-Learning delivery methods.
For those, who do not have convenient classroom training around, an eLearning
training package has been prepared. Probably the favourite form of training is Webinar
training, which comprises advantages of both, classroom training and eLearning
training. To know more, please check the website www.PRINCE2®-agile.org or
www.prince-2.net, www.project-academy.com.
The Pre-requisite for training is that the participant needs to hold a correct PRINCE2®
Practitioner certificate. If you do not intend to undertake the certification exam for
PRINCE2 Agile®, knowledge at PRINCE2® Foundation level equivalent should be
sufficient.

b) Certification
At present, only PRINCE2 Agile® Practitioner certification exists. To get it, all
participants must have a valid PRINCE2® Practitioner certificate. (Check your PRINCE2®

36
Practitioner certificate is still valid. If it has expired or you do not have this certificate,
you must register to be eligible for PRINCE2 Agile® certification exam).
The Exam is open book, means that you can have the PRINCE2 Agile® manual during
the exam. At present, only the hard copy for of exam is available. You need to take it
in a room with certified invigilator. You can take the exam through any ATO training
PRINCE2 Agile®,

11.3 Exam
The exam follows the PRINCE2® Practitioner format, where the paper is based on a
Project scenario with additional information for some questions.
There are a total 50 multiple choice questions with only 1 correct answer from 4. In
fact, more answers can be correct, but only one answer best fits the situation
described. The exam lasts 2½ hours and if English is not your native language, you get
an extra 40 minutes. To pass the exam you must have a score of 60%, or 30 out of 50.
The exam is marked by the Exam Institute with results provided to the candidate after
the mark is confirmed. A certificate is issued by the Exam Institute.

37