PRINCE2 AGILE Environments
Following on from our first article about Blending PRINCE2 AGILE projects we are going to discuss some more aspects of these two terrific project management techniques.
Agile Scope
The agile environments often allow flexibility around the scope of the project. When a request for change is issued, the change authority needs to understand what flexibility exists around the scope of the work.
Because such changes will normally be raised during the sprint itself, then the agile team are empowered to manage such changes.
As part of the sprint agile philosophy, if such change requests were to increase the scope of that sprint, then either the team could agree that change could be managed within the sprint, or the change, if agreed, would be added to the prioritised product backlog.
In this event, it is the product owner who would ultimately decide when such an approved change should be implemented – this would be a future sprint.
The Agile Business Case
In an agile environment, the project scope and the associated benefits that will bring, will probably be more fluid than in a more traditional project environment.
At the start of an agile project, the project team will list all the new feature products, estimate the costs and time of implementing each feature, and forecast the measurable benefits that each feature would provide for the users.
This list is called a product backlog and could serve as an agile version of the business case.
The backlog is a list of features, and the scrum team would review the product backlog and decide which features to deliver within the next sprint that would bring the highest benefits to the users first.
The backlog is continually ‘groomed’ as the business environment will often change during the project as well as the need to incorporate feedback from real users and customers. In this way, the product backlog is continually revised and updated – some features are added, and some features might be removed.
This process of constantly re-evaluating which features to deliver at the beginning of each sprint means that both scope and business benefits will continually change.
In order to adapt to this situation, the PRINCE2 Business Case should specify acceptable benefit tolerances. A way of doing this is to use a technique that forecasts the best case, expected case, and worst case for the project benefits.
The initial business case (created in the PRINCE2 starting up a project process), might also show the minimum amount of benefits that the project needs to deliver, to make the overall initiative viable.
When calculating an investment appraisal within the PRINCE2 Business Case, consideration should be given to the return on investment gains by users getting beneficial products earlier and the delivery of incremental subsequent sprints.
The business case should also consider the potential cost of releasing a new product every month or so and the disruption this may have to the organization’s operational areas.
Agile and PRINCE2 Planning
As you are aware, the product backlog is a list of requirements which agile called user stories – theses are the project deliverables.
Each user story describes the feature in a measurable, testable way and gives an indication of the value of the item.
Just like the Project Product Description and the Product Breakdown Structure (PBS) within PRINCE2, the product backlog identifies the main output of the project, and so might replace those PRINCE2 management products.
The normal approach for an agile or scrum project manager, is to create a highlevel Vision Statement and Product Roadmap within the PRINCE2 Starting up a Project process.
Both the vision statement and the product roadmap would play the same role as the project product description by providing the overall purpose of the products to be delivered and a high-level description of what they are.
In the PRINCE2 Initiating a Project process, the project manager would create the product backlog thereby providing more details on individual requirements or user stories that may be delivered, along with an indication of the value and priority of each one.
Each PRINCE2 management stage might contain one or more streams of work, where a working release would be handed over to the users at the end of each sprint.
For each sprint, a sprint planning process takes place. Here, the project management team would work together to plan which requirements from a product backlog to deliver in the upcoming sprint.
As part of a sprint planning, the team would take into account the resources available and the priorities of the requirements. The user stories selected from the product backlog form what is known as the sprint backlog.
If PRINCE2 product descriptions were created, the initial versions of each, would likely only address the purpose and quality criteria of the products – with the product description details added during the execution of the work package and/or sprints.
Learn Today Lead Tomorrow!
Project Management Training from just €29/month with a simple annual payment
Note that if there were only one sprint within a specific stage, this sprint planning would be the equivalent of stage planning carried out within the Managing a Stage Boundary process of PRINCE2.
If the stage contained more than one sprint, then the above stage planning would be based on the initial estimates for the likely scope of the stage, including some idea of a Minimum Viable Scope.
This Scope would be refined and adapted as the project team performs sprint planning on each sprint within that PRINCE2 management stage.
Managing PRINCE2 Quality within Agile
Within agile, product descriptions might be written as user stories or epics. In addition to including the “who, what, and why” format of the user story, it is important that the product descriptions meet all the other PRINCE2 requirements.
An example here is the PRINCE2 product description should contain a list of quality criteria, which agile normally calls acceptance criteria, in addition to indicating the skills and resources needed to implement the user story.
Most agile and scrum attach a value to each user story which is different from the PRINCE2 approach. The nearest PRINCE2 term to an agile value, is benefit.
In PRINCE2 projects, such benefits or only set up at project level within the business case. Therefore, I recommend that each PRINCE2 Product Description includes such product value/benefit.
When an agile team first generate user stories, it is quite natural to have some large user stories that have not yet got enough detail and are ill-defined at this point. These ‘super-user stories’ are called epics, which are compatable with the PRINCE2 Project Product Description.
When carrying out the PRINCE2 initiating a project process, several of these epics may be refined into user stories and/or product descriptions as mentioned above.
During the PRINCE2 managing a stage boundary process the project manager and team can create more detailed product descriptions of most products to be delivered within the upcoming stage.
This aligns well with the agile philosophy evolving the requirements for products throughout the project.
The PRINCE2 mindset could help avoid chaos by baselining or freezing high-level product descriptions at a reasonable point in time, while allowing lower level product descriptions to evolve without impacting the high-level requirements.
Because agile delivers products across a series of iterations, this will often involve a higher frequency of quality checking than in a traditional project.
Ultimately, product acceptance within an agile project, is during each sprint review, where the product is demonstrated to the customer or user.
Feedback from such a review will provide product improvement – usually carried out in the next sprint. This too contributes to the higher frequency of quality checking.
It is therefore important that the PRINCE2 project management team needs to carefully plan and budget for a higher frequency of such quality checking with the purpose of delivering robust products within a short period of time.
Agile and PRINCE2 Change Control
The general philosophy of agile approaches is to respond to and embrace change, whereas PRINCE2 talks about controlling change. Despite this, both can work together effectively on a project.
It is important that the project management team avoid over-exactness when creating product descriptions. This can be achieved by specifying product quality criteria precisely, but only when it is necessary. This reduces the number of requests for change that need to be treated formally to the issue and change control procedure.
The product management team should try to baseline only quality criteria for the purpose of the product (rather than for example performance related criteria).
It is vital that any request for change is raised during a sprint are dealt with speedily so as not to slow down the development of the products.
Change control will often take place during the daily scrum standup meeting, and so is important that the change control process can often be carried out verbally with the decision being captured by the project manager or product owner, thereby leaving the implementation to the team themselves.
Of course, if a change is authorized, it is vital that the product backlog and in its priorities are updated to reflect such a change.
Agile and the PRINCE2 Progress Theme
Within agile, products are delivered in the number of sprints, the rule here is that once a sprint starts, it cannot be shortened or lengthened.
In a traditional project, the traditional constraints on time, cost, and scope.
In addition, the Scope is normally fixed and non-negotiable. It is therefore not a surprise that traditional projects tend to come in late and over budget, since those are the only criteria that the project can control.
It is no accident therefore, that PRINCE2 recommends setting time and cost tolerances since no estimates can be 100 per cent accurate. Such a tolerance will give the project manager some leeway to manage product progress. Within the agile however, each sprint is a time-bound and so rather than increase cost, the team reduce scope.
For this reason, agile project managers focus on how much scope is being delivered rather than time or cost overruns. Once a sprint is planned, the number of people, and hence the cost, are unlikely to increase due to the fixed duration of the sprint.
The message here is that agile project management needs to focus on measuring projects progress via delivered scope.
Agile and Controlling a Stage and Managing Product Delivery
For large complicated projects, the work package might be a formal set of instructions, and the converse is true for simple projects.
Whatever the size, the project manager should use the PRINCE2 work package’s product description as a checklist to ensure that all relevant information is present.
Within an agile project, the PRINCE2 highlight and checkpoint reports might be more informal and could simply be verbal updates.
Again, within an agile project, the project manager or the team manager might facilitate the daily standups meetings, which is where the teams can report progress and examine project issues.
Rather than using reports, information radiators are the usual way of communicating project information. These easy-to-read wall charts show in a visual and pictorial way, information about the projects progress, issues, risk, and goals.
Common forms of information radiators are the Kanban Board and Burndown chart.
The Kanban Board tracks the work that has been assigned to each person and the current status of each task.
The Burndown chart tracks how much work remains against the sprint timeline. Within an agile/scrum sprint, the sign-off of the products could be done by giving reviews and demonstrations to the customer at the end of each sprint.
After such a demonstration, the project manager or team manager will run a sprint retrospective, these are like lessons learned meetings within PRINCE2, and these can help the team learn useful experience for future work.
The frequency of PRINCE2 highlight and checkpoint reports make changes to the risk profile and the products been created within a specific sprint. This flexibility should be documented in the communication management approach.
Also, the highlight and checkpoint reports may contain additional information such as progress against certain key performance indicators.
Rather than the traditional ‘command and control’ approach to project management, agile and scrum projects are based on the ‘servant leadership’ approach.
This will have a fundamental change to the way that the activities within the PRINCE2 controlling a stage process occur.
We have already discussed the way in which work packages are initiated and closed, as well as the way in which highlights and checkpoint reports are used.
It is worth making a few points on the remaining typical activities of the project manager within an agile environment.
Capture and examine issues and risks/corrective actions
These are likely to arise within the dynamic environment of the development team and such corrective actions will be carried out by the team themselves.
Therefore, the project manager will only need to deal with such issues, and risks, and required corrective actions, should they be escalated by the team themselves.
Progress feedback can be obtained by the project manager observing the daily standups meetings.
Review the stage status
As a minimum, the project manager should review and update the business case and risk register on a regular basis. Progress information is used by the project
Want to Become a PRINCE2 Practitioner?
PREMIUM SUPPORT GUARANTEE
Our primary goal is to meet your needs in the most professional and efficient way possible. We believe our Online Training Classes will transform your learning life. Having easily accessible training gives you more peace of mind than you ever thought possible. We love answering training questions and helping you with classes you are enrolled in. For a quick reply to any questions just leave a support ticket.
