Why combining PRINCE2 with Scrum?

I think Scrum is great and we all should use the Scrum approach whenever possible. The ‘whenever possible’ bit does concern me. I’m not at all happy with the ‘implement Scrum as cleanly as possible and work from there’ approach. Sometimes the gap between reality and the ideal agile approach is too wide to bridge, which results in a failed project and frustrated people. It isn’t healthy nor productive and just isn’t necessary. (And also isn’t agile in itself).

I’ve learned by experience that there’s only so much change people can endure. A little bit of radical change so now and then is acceptable and healthy, but not too much in the same time frame and certainly some time is needed to get accustomed to the new situation. Implementing lean is also a lean process, an iterative process of change, learn and adapt.

So the first reason why I think PRINCE2 and Scrum combine very well is because people are accustomed to PRINCE2 and a PRINCE2 project management wrapper around Scrum makes the Scrum implementation much easier.
The second reason is because I think the PRINCE2/Scrum combination does add value to the customer.

That said, how in earth can a ‘heavyweight’ method like PRINCE2 be combined with a lightweight Scrum approach?

PRINCE2 is more agile than you think

PRINCE2 doesn’t have a great reputation in the agile world. PRINCE2 is anti-agile and applying PRINCE2 makes you an evil ‘command and control’ type of manager.

PRINCE2 actually is intended to be scaled down to the project’s context. The manual explicitly states that ‘right-sizing PRINCE2 is a critical success factor’. The 2005 version of the PRINCE2 manual doesn’t explain right-sizing PRINCE2 very well though. It’s written in a very formal style and (almost) doesn’t mention the choices you can make. This is where the bad reputation comes from. If you implement PRINCE2 straight from the book, usually very heavyweight, failure is imminent.

This all has changed with the 2009 version. PRINCE2 principles are introduced to explain what’s really important. The implementation of these principles is highly adoptable. The manual also clearly explains that PRINCE2 can be merged with other methods. This is because PRINCE2 is only a project management framework, it says nothing about delivery methods. PRINCE2 also isn’t waterfall. The word even doesn’t exist in the manual.

Positioning Scrum within the PRINCE2 framework

The Scrum process is all about delivery. Fast and effective delivery is key. Within PRINCE2 the delivery process is a black box. PRINCE2 is all about managing the project’s process.

This makes Scrum a natural fit to the PRINCE2 ‘Managing Product Delivery’ process. This also makes PRINCE2 the project management wrapper around Scrum. I think this is a great combination and I’ll explain this below with some real life problems we all have with Scrum. I’ll also explain some PRINCE2 implementation choices which are needed with the PRINCE2/Scrum combo.

PRINCE2 solutions to Scrum problems

The Product Owner ‘superhuman’

The Product Owner is the one and only person representing the customer. This person also represents all stakeholders. Frankly, it’s very, very hard for anyone to meet all the requirements for this job. It’s clearly one the most common problems we have with Scrum. There are some solutions, like the ‘proxy’ Product Owner, but PRINCE2 has a much more adult and proven approach; the project board.

The project board knows three roles: Executive (accountable for the business case), Senior Supplier (accountable for delivery), Senior User (represents the users, accountable for the product’s requirements). Usually the Senior User is represented by a user team on an operational level.

It’s very easy to split up the Product Owner’s responsibilities between the Project Board’s roles, it doesn’t change the Scrum process. It actually adds value because Scrum doesn’t cope well with customer/supplier projects where the supplier takes commercial risks.  That’s because the supplier isn’t represented in the Scrum process.

The project board doesn’t make a project more heavy weight. It might seem so but in real life you still have the same talks with the executives involved even when a project board doesn’t exist. The project board actually makes your life as a project manager easier because in PRINCE2 the project board is accountable for the project’s success, not you. This makes the board your ally in removing impediments, also because the board members usually have the authority to do so.

The CSM: responsible for the Scrum process, not for results

Most people don’t seem to know that a PRINCE2 PM is not accountable to the project’s outcome, the Project Board is. That’s why the project plan must be approved by the Project Board, that’s why all important decisions are made by the Project Board. PRINCE2 has introduced the concept of tolerances to make the project’s process more independent (management by exception). The fact remains that the PM’s main duty is managing the project’s process. That’s not unlike Scrum, where the CSM also isn’t accountable to the project’s outcome.

In my view both the PM and CSM have the same challenges and pitfalls. Managing the process and creating strong teams. The difference is that a CSM hasn’t authority over the team, the PM does. Sometimes problems arise in Scrum projects when the CSM exceeds his/her authority when trying to impose changes in the team’s process. Sometime problems arise in non-Scrum projects when the PM rules by ‘command and control’. Sometimes problems arise when the customer isn’t used to a self-managing team and expects more from a CSM then Scrum allowes.

In all cases it isn’t easy to create a focused and self managing team. IMHO being a PM doesn’t impediment the co-existence of a self managing team. There always exists boundaries of self-determination and a PM with the proper attitude and management style also is capable in creating an effective team. A difference is that the PM does have the authority to impose changes when necessary.

Of course in the combination PRINCE2 and Scrum it also isn’t a problem at all to have a PM with one or more Scrum teams, each having a CSM.

The project startup

There exists different views how to implement a Scrum project, especially the startup phase.

One approach is to ‘just start’, and manage the implementation impediments along the way. This shouldn’t be a problem, because impediments are expected and the iterative Scrum approach with Sprint Retrospectives is an excellent way of learning and adapting.

The problem I have with this is that during the first few Sprints a lot of impediments are to be encountered. I find it difficult gaining trust and confidence in a Scrum approach when a lot of ‘problems’ occur. In my experience managing expectations helps but isn’t enough. I prefer a preparation phase, sometimes called a ‘Sprint zero’.

Within PRINCE2 the preparation phase is an essential part of the method. The processes ‘Starting up a project’ and ‘Initiating a project’ are used to get approval to starting the project, based on a common understanding of the project’s business case, methods and procedures and also is important to get commitment from the people involved. This preparation phase doesn’t have to be heavyweight and can be executed quickly.


A traditional sequential approach offers confidence by predicting a delivery date, costs or a fixed scope. We all know that that won’t happen, but a commitment is given which is something a customer likes. Scrum doesn’t offer this level of commitment. There exists more uncertainties. Fixed date yes, but no fixed scope. Only after some Sprints the outcome becomes somewhat more predictable. It is something the customer has to live with. I’m not saying that this is wrong. I’m only saying that it’s difficult for a customer.

Scrum has some instruments that help, like velocity or the burndown chart. It still is an alien approach to most people, certainly during the first few Sprints.

I’ve experienced that a PRINCE2 wrapper around Scrum helps a lot in gaining trust, especially before or during startup. PRINCE2 is well known, the customer is accustomed to the instruments that PRINCE2 offers and the PRINCE2 process ‘Directing a project’ is a more explicit means to influence the project’s progress than the Product Owner tasks as described in Scrum.

Product Backlog

A problem with the Product Backlog is keeping overview. The list is very dynamic and contains all kinds of User Stories: small/large, different priorities, different business domains or processes. Also sometimes interdependencies exists (which shouldn’t but it happens anyhow).

I can’t help notice that the PRINCE2 technique called Product Breakdown Structure is useful in creating some order in the chaos. It’s not unlike other solutions I’ve seen explained in blogs.


Within Scrum there’s no explicit method for managing risks. Partly it isn’t a problem because a lot of risks are managed implicitly by delivering in short intervals. Each Sprint is a checkpoint in which both solution and process are discussed and improved. This is a very effective approach for problems inside the sphere of influence of the project.

In my opinion there is a problem with risks that lie outside of the team. The CSM is reponsible for managing these problems (impediments) but he/she has limited authority. Also it isn’t an pro-active aproach to problems. Problems should be managed when they are still risks. (Although a valid risk-countermeasure is ‘do nothing’, which can work with an agile approach).

The PRINCE2 approach with explicit riskmanagement and an active involvement from the project board to me works very well. It shouldn’t cost too much time and effort and can add a lot of value. The PM (CSM) can deal with risks/problems within the team’s process, the project board can deal with the other risks and problems.

Agile PRINCE2 implementation

There’s more to making PRINCE2 agile then described above.

Agile business case and Product Definitions

PRINCE2 nowhere states that scope is fixed or that the project’s business case is fixed. It’s perfectly allright working with an evolving business case. (Though most people seem to think otherwise, maybe because most people think PRINCE2 equals waterfall). There is no impediment here combining PRINCE2 and Scrum.
The agile approach is to start with a high-level business case and amend this business case after each Sprint. In addition to this you can also start with a single high-level product definition (like a Vision statement). For single products I use Scrum User Stories in stead of product definitions. The PRINCE2 format for a product definition is much more comprehensive, but most information is about the process of creating, validating and accepting the product. With Scrum/PRINCE2 it would be useless repeating this information over and over again in each User Story because it’s the same for each story. (Though in special cases the PRINCE2 format might be handy).


The PRINCE2 management approach is to manage ‘by exception’. At the start of the project specific boundaries (tolerances) are established in which the team team can move freely. The project board only becomes involved when there is danger that the project moves outside of these boundaries. This works very well with an agile approach. The tolerances for money and time can be fixed (no tolerance) where the tolerance on scope can be used to establish a minimal scope to be delivered, for instance all User Stories with a ‘Must Have’ Business Value.


The new PRINCE2 2009 manual states explictely that templates other then the official PRINCE2 ones can be used for reporting, as long as you report what is important to your customer.  It is a good idea to use specific Scrum information like release planning based on Velocity and Product Backlog, Lessons Learned based on Sprint Retrospectives.

Sprints or Phases

Since Scrum iterations (Sprints) follow each other closely, there is no time to get a formal approval from the Project Board to start the next Sprint. PRINCE2 states that approval is mandatory for each next project phase. This really isn’t a problem, there are a couple of solutions.

You can execute several ‘technical phases’ (Sprints) within one management phase and in this way ask approval for several Sprints at once. My favorite solution is to agree on an implicit approval for the next phase. I use the Sprint Planning meeting as an informal approval for the next phase. The Sprint Backlog is my phase plan. During the first days of the next Sprint I deliver a phase report, describing the results of the previous Sprint and the consequences for the release planning. Also tolerances are useful here. When the Sprint results or release planning are within the boundaries approval can be obtained automatically.

Lessons Learned

Lessons Learned are essential for any effective project. This is the case with both PRINCE2 and Scrum. In a traditional approach lessons learned usually aren’t. That’s because when lessons are only discussed when the project is finished, it is of no use to the project anymore. There is a large difference when compared to Scrum. The project’s process for each Sprint remains basically the same, you have the same people on the team, so you have lots of opportunities to try out solutions and learn. I also make this process of learning explicit to the customer by reporting the Sprint Retrospective results in each phase report.


Scrum is a highly effective approach for getting results. It does take a lot of thinking, knowledge and wisdom to make the right choices when implementing Scrum. Implementing ‘Scrum by the book’ in my opinion won’t always work, because there are too many problems to resolve, the change is too large. The problem with changes is that you can’t change instantly to an ideal. Changes are done from reality and in small steps.

In the real world PRINCE2 complements Scrum very well. The team works with Scrum, the project manager largely works with PRINCE2. Both methods are compatible. The real advantage of the combination is that a PRINCE2 layer around Scrum makes it much easier for a lot of organisations to move to an agile approach and more successful project outcome.

Good Management!