PRINCE2 and SCRUM - can they co-exist? Yes. Further info or register for webinar at MasterBusinessChronicles.com

1. Prince2 and Agile / Scrum
Version 1.0
By Johann Tambayah
There are many papers on the internet which detail how the agile methodology of Scrum could be integrated into Prince2 but from what I have
found many of these sites do not go into deeper detail on how this is to be achieved. Many of them suggest that Scrum should only be addressed
in the ‘Managing Product Delivery’ process of Prince2 however whilst this is possible the author does not believe this is sufficient in its entirety.
Before diving into detail on how this is to be accomplished (and more so tailoring Prince 2 to Scrum) we must ask ourselves why we would want
to integrate Scrum and Prince2.
With the dawn of 2011 most job boards in the UK and Australia seem to be flooded with job descriptions for ‘agile project managers’ where
project managers are sought with formal project management skills (such as those in Prince2 and via the PMP / PMBOK) as well as those with
formal training in Scrum (the leading agile methodology today, preferably being Certified Scrum Masters). This is somewhat peculiar given the
Scrum framework removes the role of the project manager from its project environment. From the conversations I have had with such
organisations that seek ‘agile project managers’ as well as recruitment agencies seeking to fill these roles, what I deduce is that most
organisations are not entirely comfortable removing the role of the project manager from their organisation. This may be due to either resistance
to change or perhaps there are other reasons, such as Prince2 being considered the tried, tested and prevailing norm within government bodies in
the UK, Australia and certain parts of Europe. Prince2 does have its major successes and companies are not keen to waiver from this. Without
focusing on the justification of the role of a project manager within an organisation what must be remembered is that Prince2 is not a project
management function alone. Prince2 is a framework for the entire organisation. Prince2 is an organisation structure that has the capacity to
deliver projects successfully. It provides management frameworks and roles / responsibilities for project executives, programme management,
users, suppliers, project managers, team leaders, etc.
Prince2 states that a project must be tailored to fit its environment. Within this ‘tailoring’ it is possible to use Scrum to deliver projects. Why
would you want to integrate Prince2 and Scrum? Prince2 provides structure, roles, responsibilities, a framework and the necessary
documentation that is required on many high-end projects such as government or funded NGO projects. Scrum provides a delivery mechanism
1|Page

2. built by the ‘builders’ that focuses on the best possible ‘building’ technique that places customer orientation as key and embraces change. Both
frameworks embrace change, customer orientation and delivering in stages or iterations.
This document presents a framework for Prince2 and Scrum to exist and succeed in the same environment. It answers the questions –
•
•
•
Is it theoretically possible to implement Scrum within a Prince2 environment?
How do we implement Scrum within a Prince2 environment?
Does a project environment remain Prince2 when you implement Scrum?
Please note that this document assumes the reader is familiar with Prince2 and Scrum terminologies and frameworks.
Does a project environment remain Prince2 when you implement Scrum? For a project to be deemed Prince2 it must adhere to the 7 Prince2
Principles. The table below details how Scrum integrates into the 7 Prince2 principles.
Prince2 Principle
Scrum Integration
Continued business justification i.e. the Business Case for the Scrum encourages the Product Owner to revisit the product backlog
project must exist during the life cycle of the project
throughout the project to ensure the requirements are prioritized according
to the business justification and updates are made to the priority scale based
on this. It is possible to change the Product Backlog items in order to
ensure business justification.
Learning from experience i.e. lessons from past projects are Scrum encourages a sprint retrospective at the end of each sprint where the
documented and the knowledge passed on
team asks itself ‘how could we have done this better?’ and this knowledge
is documented for the next sprint or project. Scrum encourages cycles of
adapting based on previous learning.
2|Page

3. Defined roles and responsibilities i.e. Project Executive, Project Scrum has its own set of defined roles and responsibilities e.g. Scrum
Manager, Senior User, Senior Supplier, Project Support, Project Master, Product Owner and team. Scrum does not use some of the Prince2
Assurance, etc.
roles however this would not be an issue when the two frameworks are
integrated as the responsibilities are never compromised. Where certain
roles are removed e.g. Team Leader; the responsibilities of this role are
passed on to other roles.
Managed by stages i.e. each project must have a minimum of 2 Scrum delivers in iterations called sprints which could be considered stages
management stages (control points)
Managed by exception i.e. if tolerances for time, cost, quality, Scrum manages exceptions by either placing incomplete sprints back on the
risk, etc. are compromised, an exception must be raised by the product backlog or dealing with exceptions at sprint reviews by consulting
project manager to the project board
with the Product Owner. The Product Backlog could be modified at any
point to handle exceptions with close collaboration between the Scrum
Master, the team and Product Owner.
Focuses on products and their quality. This is documented in
‘product based planning’ techniques where project and product
descriptions detail acceptance criteria and quality expectations
for each deliverable.
Scrum ensures that the team reviews the Product Backlog and converts this
into the Sprint Backlog. The Sprint Backlog lists tasks to be completed
however prior to this the team must consult with the Product Owner on
‘user stories’ and acceptance criteria which will be used to develop the
product and judge its quality at sprint reviews.
Tailored to suit the particular project environment
Scrum could be used within a tailored Prince2 solution as long as the
Prince2 principles are not compromised.
3|Page

4. Hence it is absolutely possible to merge both the Prince2 and Scrum frameworks.
Is it theoretically possible to implement Scrum within a Prince2 environment?
Yes.
How do we implement Scrum within a Prince2 environment?
Prince2 is made up of 7 Principles, 7 Themes and 7 Processes. I will now discuss the Prince2 Themes and Processes detailing how Scrum could
be implemented within Prince2.
4|Page

5. Prince2 Themes
We will briefly discuss each Theme and determine how Scrum could be integrated within each Theme and more so, how Scrum compliments
Prince2.
1. Business Case
This theme answers the question - is the project is desirable, viable, feasible or achievable?
The Business Case is the implementation of the Prince2 principle ‘is their continued business justification for the
project?’ It dives into determining what the benefits for the project are, the reasons for undertaking the project, the
costs involved, the business options, the timescale and the major risks.
The Business Case for Scrum is determined by the product owner. The Product Owner presents a prioritised list of
requirements to the Scrum team. The team works with the Product Owner to determine the Sprint Backlog which
includes user stories and acceptance criteria. This process is similar to the product based planning approach used by
Prince2.
The Prince2 Business Case is a high-level document in the organisation and could certainly include the initial product
backlog.
2. Organisation
Prince2 puts into place an organisational structure for projects. The Executive is the key decision maker on the project
and the ultimate authority. The Senior User is the end-user representative of the project and the Senior Supplier is the
representative of the project suppliers. These three key roles form the Project Board.
The Project Manager reports to the Executive. The team reports to the Project Manager most often led by a Team
Leader.
In addition there are two more roles which are Project Assurance which act on behalf of the project board and may
advise the Project Manager on certain aspects as well as conduct independent checks. The other role is the Change
Authority which is capable of approving change requests in the absence of the project board. A Project Manager may
5|Page

6. also have a Project Support function to assist him or her in documentation and other administration functions.
The major roles in Scrum are the Team, Product Owner and Scrum Master. The Scrum methodology removes the roles
of the project managers and team leaders.
The Prince2 Project Manager is responsible for planning, delegating, monitoring and controlling the project within
tolerances and motivating team members. So how do we handle the clash in roles seen in the Prince2 and Scrum
frameworks? The only solution here would be to administer a ‘give & take’ policy that is reasonable and amicable to
both frameworks. As discussed previously Prince2 is an organisational framework for projects. Scrum could be used
for the delivery of the project itself i.e. the teamwork; where the team leader could be played by the Scrum Master and
the Project Manager would continue his/her work in the start-up of the project, its initiation, other Prince2 processes,
stakeholder management, reporting to the board, assisting in the removal of impediments with the Scrum Master and
motivating the team. For Scrum and Prince2 to work together the Project Manager would be required to let go of
his/her responsibilities in the product delivery.
The Product Owner role would ideally be played by the Prince2 Senior User as this individual would know the product
best. However it is also possible for the Project Manager to play this role as he/she is involved in the early stages of
the project together with the Senior Users in putting together the product descriptions or in this case the product
backlog. The Project Manager could request the Senior Users to be present at Sprint Reviews.
3. Quality
The key purpose of this theme is to ensure the project delivers a product that is ‘fit for purpose’.
Prince2 places a lot of emphasis on quality, as does Scrum. In Prince2 the Project Manager puts together a Quality
Management Strategy which details what quality standards that will be implemented on the project, the records to be
maintained and the responsibilities / roles. It details both in-process checks such as internal testing as well out-ofprocess checks such as formal Quality Review Techniques. It details the maintenance of a Quality Register which is a
formal record for quality checks.
Scrum details the use of test automation (in-process) during each Sprint and Sprint Reviews which follow very similar
formats to the Prince2 Quality Review Technique. Prince2 and Scrum are very similar in their commitment to quality.
6|Page

7. 4. Plans
Plans in Prince2 are made using product based planning techniques. This involves breaking a project down into
products and then breaking these products down into tasks. This is usually done at the very beginning of the project
i.e. project initiation, and involves work being done by the Project Manager and Senior Users. This forms the Project
Plan. Prince2 also uses stage plans, team plans, and exception plans (when project tolerances are threatened or change
requests are made to the baseline). Prince2 requires the use of a project schedule and most often Gantt charts are used
to track project progress (although tools and techniques for scheduling and monitoring progress are not specified).
Scrum involves the team deciding on how much work they want to take on from the Sprint Backlog. This work is
carried out in a sprint before the next sprint plan is produced. Products are delivered in iterations (which makes agile
techniques such as Scrum very effective). Product burn down charts are maintained by the team and Sprint burn down
charts are maintained by the product owner which reveal how long the project should take to complete.
Prince2 and Scrum are similar in that they both involve stage plans or sprint plans and they both use product based
planning techniques.
If there is a change to the baseline requirements the Project Manager (Product Owner) would still need to provide an
exception report to the Project Executive (ultimate authority) and the Project Board. Similarly if projects are taking
longer than anticipated to complete or any other tolerances are threated, the Project Manager would need to provide an
exception report to the Project Board. The Project Board could either approve or disapprove the report and if they wish
to, a new exception plan or new baseline plan would be produced by the Project Manager. This new plan could be
used to update the Product Backlog.
It is possible for the Project Manager to maintain a high-level schedule which details tasks external to the delivery in
detail e.g. prepare the product descriptions, prepare the End Project Report, recommend follow-on actions and prepare
the Lessons Report. It is also possible for the Project Manager to update his/her schedule based on the burn down
charts such that he/she is able to maintain a schedule and Gantt chart for delivery.
5. Risk
The Prince2 Project Manager is required to develop a Risk Management Strategy as well as open up a Risk Register.
This involves determining the identification, assessment, planning, implementing and communicating of risks as per
normal Prince2 operations together with detailing risk actionees, the risk appetite, etc. The Risk Register would log
7|Page

8. risks and detail mitigation plans.
The only difference in the Scrum environment is if a risk does materialise its mitigation plan would also be placed on
the Product Backlog for the team to commit to on their next sprint. This would be prioritised accordingly by the
Project Manager / Product Owner.
6. Change
Prince2 suggests that any change to the baseline must be approved by the Project Board. A change could be a bug or
off spec, a change to the baseline requirement itself or a problem / concern. Scrum’s call to fame is that change is
possible at any time during the project other than for when a sprint is in progress. The Project Manager in the capacity
of the Product Owner or in conjunction with the Senior User must document a change in the form of an Exception
Report and once approved by the board have the team implement it on their next sprint if this is a priority.
The Project Manager should still be able to manage a Prince2 Issue Register and capture and deal with change in this
manner. The Scrum Master could also maintain this document listing impediments on the project which could include
problems / concerns or bugs / off-specs. The Project Manager and Scrum Master would be able to work together in
removing impediments and dealing with these issues.
7. Progress
The team in scrum does not report to the Project Manager or the Product Owner or the Scrum Master. This eliminates
the Checkpoint Report of Prince2. However the same information could be captured from product burn down charts
and sprint burn down charts. The Project Manager could use this information to produce his/her Highlight Report to
the Project Board. This would also enable the Project Manager to track progress.
The Prince2 lessons report and logs are similar to the sprint Retrospective and capture the same information.
Schedules could be handled as per the suggestions under the Plan section above.
8|Page

9. Prince 2 Processes
Having spoken of Scrum and the Prince2 Themes let us have a look at the Prince2 Processes and the implications of working with Scrum.
1. Starting up a project
This process remains largely unchanged from the Prince2 norms.
The Project Brief is prepared which is the inception of the project. The Project Board is setup and the Project
Manager appointed. It is wise to decide on the roles of the Scrum Product Owner and Scrum Master.
Previous lessons from projects are reviewed and it is also prudent to refer the previous Scrum sprint retrospective
documents.
The initial Product Backlog should be created at a higher level.
The outline Business Case is prepared.
In this Process make note of the ‘Project Approach’ which must detail the use of Scrum in delivery and its impact
on Themes and Processes. Special care must be taken to note that Scrum education is begun at the Project Board
and within this Process, such that the Project Board is aware of the intricacies and differences when contrasting
with traditional non-agile methodologies such as the Waterfall model.
2. Directing a project
This process is widely unchanged e.g. authorising initiation, authorising the project, ad-hoc direction, authorise
closure, etc. except in the case of authorising stage plans. The Project Board could be presented with the Product
Backlog and explained what items are being delivered in the next sprint.
The project board must be made aware of the Scrum methodology particularly in the case of the Senior User who
will be expected to meet up with the team on Sprint Planning meetings and either take on the role of the Product
Owner or assist the Project Manager (taking on the Product Owner role) in prioritising products and defining
9|Page

10. acceptance criteria for the sprint reviews.
3. Initiating a project
In this process the project manager would be expected to create the below documents taking Scrum into
consideration –
a) The Risk Management Strategy – stating changes suggested in the Risk theme
b) Configuration Management Strategy – stating changes suggested in the Change theme
c) Quality Management Strategy – stating changes suggested in the Quality theme
d) Communication Management Strategy – stating changes suggested in the Organisation theme. The project
manager would be expected to decipher which stakeholders require what information. It must be stated that
reports such as the Checkpoint report will no longer be used and alternate reports comprising of information
gathered from the burn down charts will be presented.
e) Setup Project Controls – This details information such as the format and frequency of communication, the
number of stages / sprints, project tolerances, etc.
f) Creation of the project plan – stating changes suggested in the Plan theme.
I would suggest conducting the ‘scrum kick off’ in this process.
These documents form the Project Initiation Document in some organisations known as the Project Charter.
4. Controlling a stage
This stage has often been known as the day-to-day activities of the Project Manager.
There are no Prince2 Work Packages in this model.
The work to be done is presented in the form of a Product Backlog which is handed over to the team and
10 | P a g e

11. discussed at Sprint Planning Meetings. Sprint planning meetings are broken down into 2 parts –
1) In part 1 the team asks questions about the product backlog so that it can be broken down into tasks.
2) In part 2 the team decides on how to go about delivering the project and how much they will commit to a
sprint
As mentioned previously, the Product Backlog (which includes user stories and acceptance criteria) is broken
down into a Sprint Backlog by the team. The team then proceeds to decide on how much work they will commit
to a sprint and will inform the Product Owner of this. At the end of a sprint the Sprint Review takes places where
products that are potentially shippable are presented to the Product Owner.
The monitoring of progress is judged by the product and sprint burn down charts. This information details the
project’s progress and estimated time of completion. This information could be summated in the Project
Manager’s Highlight report to the Project Board.
The project manager would be expected to maintain his Risk registers, Issue Registers and other documents as is
the norm in Prince2.
5. Managing Product
Delivery
This process could be widely implemented using Scrum. There are no Prince2 Team Plans as they are replaced by
the Sprint Backlog, Product Backlog and burn down charts. Sprints are conducted (cycles of development,
inspecting and adapting).
6. Managing a stage
boundary
The Sprint Review and Retrospective takes place here.
The (re)prioritised Product Backlog is revisited to determine what work is to be done next. The next Sprint
Planning meeting is conducted.
The Business case should be revisited to ensure the Product Backlog (which has possibly been changed) is still on
path to produce the desired outcomes (business justification).
11 | P a g e

12. The project manager should produce his/her Prince2 End Stage Report which could include details on the Sprint
Retrospective and Sprint Review as well as details on the next sprint.
7. Closing a project
This Process follows Prince2 i.e. prepare the End Project Report, prepare the follow-on-recommendations and
other documents.
The sprint retrospective is documented (Prince2 lessons report).
The above should provide you with an idea on how to implement Scrum within a Prince2 environment. The key concept to keep in mind is that Scrum and
Prince2 need to be tailored to the project environment.
12 | P a g e

13. Bibliography
Managing Successful Projects with Prince2 2009 Manual, Office of Government Commerce, The Stationery Office; 2009 edition (January 6, 2009)
The Scrum Primer – Version 1.2, 2010, Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde
About the Author
Johann Tambayah is a certified Prince2 Practitioner and a certified Scrum Master.
He is a Senior Project Manager holding an MBA (Leicester) and BSc (Hons, London) with over 10 years of project management experience. He has worked
for large scale World Bank directed projects, online / e-Commerce projects and large scale government sector projects in Australia, UK and South Asia.
Email: Johann@MasterBusinessChronicles.com
www.MasterBusinessChronicles.com
-End-
13 | P a g e