PRINCE2 7th Edition AGILE EXAM CRAM
Would you be interested in a FREE downloadable AGILE EXAM CRAM?
Become a better Agile project manager with Agile-blended PRINCE2
Progress your Agile skilled career, improve your earning potential and bring value to your organisation
Learn the fundamental skills needed to run a successful Agile project with PRINCE2
Our AGILE EXAM CRAM summarises all the PRINCE2 7th Edition Exam syllabus content.
Futureproof your career with PRINCE2 7th Edition, with an updated version of the globally recognised project management framework.
Our PRINCE2 AGILE Guide is intended for project managers and aspiring project managers.
PRINCE2 7th Edition AGILE Exam Cram
Download the Projex Academy PRINCE2 AGILE EXAM CRAM for free below:
The PRINCE2 delivery methods
The delivery method is how the project’s work is to be delivered. The project may rely on one or more delivery methods to create the required products.
The PRINCE2 method does not assume or require any specific delivery method. It allows for any approach to be used throughout the project’s management and specialist work to produce the project products.
PRINCE2 provides a controlled environment for specialist delivery methods. It does not assume or require any specific delivery method.
Any approach can be used through the separation of the management of the project and specialist work to produce the project products.
It is important that the approach to managing progress complements and supports the project’s chosen delivery method rather than opposes it.
Typical delivery methods include:
Linear-sequential approach:
Each delivery step to create the products occurs in sequence, and the product is made available during or at the end of the project (for example, in a construction project where requirements are being gathered and design occurs before construction starts).
For a project using a linear-sequential delivery method, the focus may be on when the stage’s products will be complete and for what costs. In this way, the project board can be confident that there is a robust basis to move from the current stage to the next.
In a linear sequential approach, steps occur in sequence, and the product is available during or at the end of the project.
Iterative-incremental approach:
This approach is often, but not exclusively, used for product development, where requirements gathering, design, development and/or coding, and testing occur iteratively throughout the project’s lifecycle.
This approach is often referred to as an agile approach.
For a project using an iterative-incremental delivery method, it will typically be more appropriate to focus on tracking how much of the requirement is being met by the end of the sprint rather than how long it will take to complete the products.
The tolerances would have been set in accordance with this.
An iterative-incremental approach, also known as the agile approach, involves steps occurring iteratively throughout the project. In a hybrid approach, different elements of the project use either of the two approaches.
An iterative-incremental approach may require more information on the benefit tolerances, priorities, and timescales.
Additionally, details of the extent and sequence of the scope may also need to be delivered.
For projects that have development teams using agile development methods, the PRINCE2 team manager role may be held collectively by the development team.
Determining how to divide the project into stages will be influenced by the delivery method (iterative-incremental or linear-sequential)
A project using an iterative-incremental delivery method with defined timeboxes will typically fix time and cost and vary in scope. In this case, time and cost will have much tighter tolerances than the scope.
Product descriptions for projects using an iterative, incremental delivery method, such as agile, may include requirements, features, epics, and user stories.
Hybrid approach: some project elements use a linear-sequential approach, while others use an iterative-incremental approach.
For example, a linear-sequential approach can be used to develop the infrastructure of a service.
Then, an iterative, incremental approach can be used to develop the customer service portal so that users can access the service.
Tailoring PRINCE2
The project initiation documentation captures how PRINCE2 will be applied and tailored for the project.
For example, a supplier may wish to use their in-house product development framework, which is based on an iterative-incremental delivery method and agile management approaches.
To avoid potential confusion, the project manager might propose to:
- Map and define terminology between PRINCE2 and the supplier’s agile management approaches.
- Add the project team roles of ‘customer subject matter expert’ and ‘supplier subject matter expert’ to the agile team, representing the customer and the supplier, respectively.
- Add a coach to guide the teams in working effectively using PRINCE2 and the supplier’s in-house agile method.
- Collaborate and communicate according to agile working methods, such as a daily stand-up, and support agile reporting tools like information radiators.
- Define project procedures, such as working with sprints or work packages, product descriptions, or user stories, and how to use these in the project.
When using the iterative-incremental approach, such as agile, the project’s scope is typically flexible to embrace adaptability and ensure completion within a fixed time and budget.
Therefore, benefits should be expressed not as a target estimate but rather as a range relating to the amount of scope delivered.
One way to present the estimation of the benefits is to present different scenarios for the scope and the benefits in a business case, for example:
- This is a best-case scenario describing the benefits expected when all (must-, should-, and could-have) requirements are delivered.
- Expected-case scenario describing benefits expected when must-have and should-have requirements are delivered.
- Worst-case scenario describing benefits expected when only must-have requirements are delivered.
The worst-case scenario showing the lowest expectation of the amount of scope delivered should also show that the project is still viable.
Delivery method roles
When a project deploys a specific delivery method, the project manager must understand how the roles prescribed by the delivery method align with PRINCE2 roles.
Sometimes, a simple terminology change and minor role description amendments will suffice. For example, iterative-incremental product development techniques often include the role of product owner, which could be aligned to the senior user role.
In other cases, distinct roles may need to be added to the project management team structure along with agreement on how they relate to the PRINCE2 roles.
Questions to ask are:
- How will the project manager liaise with teams when they are using different delivery methods from each other (such as a hybrid of linear-sequential and iterative-incremental)?
- If self-organizing delivery teams are used, how do they relate to the team manager role?
- Would the team manager role be held by a scrum master, held collectively by team members, or would the team manager’s responsibilities be split between team members, the product owner, and the scrum master?
Management by exception is essential, to enable the PRINCE2 method and iterative incremental techniques to work together effectively.
This empowers the project management team and enables it to self-organize within clearly defined boundaries.
PRINCE2 Project and stage plans
The PRINCE2 planning techniques can be applied in linear-sequential and iterative incremental projects.
The timescale, resource, and people requirements must be established when preparing the project plan and before committing to major expenditures on the project.
This information is held in the project plan and the project manager should confirm the delivery method (linear-sequential, iterative-incremental, hybrid), and assess its implications for planning.
The product flow diagram helps the project management team decide whether the project should be delivered linear-sequential or iterative-incremental.
For linear-sequential projects, most planning effort is applied upfront in the
processes of starting up a project and initiating a project. Well-understood products and mature delivery activities often characterize these projects.
Iterative-incremental projects focus on the amount produced over a fixed period (such as a sprint or a timebox). The goal is to deliver an initial product quickly and refine and improve it iteratively.
The project plan should state whether each work package will be delivered sequentially or in an iterative, incremental manner.
In an iterative-incremental project, some work packages may be detailed in a subsequent stage plan, but their general purpose and scope should be stated in the project plan.
The scope of a plan is defined by the set of products to be delivered. Scope tolerance (if used) should be a note or reference to the plan’s product breakdown structure.
Scope tolerance at the stage or work package level is particularly useful if applying an iterative-incremental development method such as agile.
PRINCE2 Project controls
The level of control required by the project board after initiation needs to be agreed upon, and the mechanism for such controls needs to be established, as does the level of control required by the project manager of the work to be undertaken by team managers.
Project controls enable the project to be managed effectively and efficiently, which is consistent with the scale, risks, complexity, and importance of the project.
Effective project controls are a prerequisite for managing by exception.
Project controls should include confirming the delivery method (linear-sequential, iterative-incremental, hybrid) and assessing its implications for project controls.
PRINCE2 Project Stages
The goal of the project plan is to give the project board and the project manager confidence in proceeding with delivery.
PRINCE2 structures the project management on a stage-by-stage basis. Combined with the Focus on Products principle, managing by stages helps the project management team plan and deliver what is required when it is required.
Determining how to divide the project into stages is a matter of balancing:
- the delivery method (iterative-incremental or linear-sequential) with the sequence of delivery activities
- the type of people and resources involved
- the number and timing of key decision points
- the amount of risk the project can manage
- how far ahead in the project it is sensible to plan.
The number of stages can vary based on the nature of the products and the necessary delivery activities. A greater number of stages increases the degree of control, but every stage boundary requires effort to manage.
Therefore, there is a trade-off between the degree of control and the level of management overhead on the project.
For an iterative-incremental project, the project plan may provide multiple delivery stages in which the quality and acceptance criteria are refined in parallel with developing the required products using a product backlog.
Writing PRINCE2 product descriptions
The required products are described in more detail when a project is initiated. The project manager elicits the user’s requirements for these products and documents them in one or more product descriptions.
The project manager also consults with subject matter experts to determine requirements related to how these products are procured, developed, tested, used, and supported after acceptance.
The definition and analysis of products may be an iterative procedure.
In a linear-sequential project, the product descriptions should be sufficiently detailed to enable the estimation of costs and time with an appropriate level of confidence.
However, in an iterative-incremental project, the detailed requirements for products may be developed in parallel with the products themselves, and a high-level set of product descriptions may be sufficient to proceed with the stage in which they are to be developed.
Projects rarely have the luxury of fulfilling all user expectations, so it is helpful to prioritize quality specifications for each product to ensure that the most important requirements are met.
PRINCE2 Scheduling
Project schedules provide information on the sequencing, dependencies, durations of activities, and milestones.
Various scheduling and presentation techniques can be used, including a Gantt chart, spreadsheet, and product checklist.
Activity flow board: When using an iterative-incremental delivery method, this technique shows how each product or product component progresses through development or delivery.
It is used in Kanban boards as well as other tools that are often used in iterative-incremental projects.
Estimating
A variety of estimating techniques are available to project managers. These include the following:
Top-down: This technique assumes that the costs, duration, and level of effort of the major products and work packages can be estimated with high confidence.
These are then allocated to subordinate elements of the product and work breakdown structures.
This technique could be used for an iterative-incremental project in which delivery is structured into stages and sprints with fixed timeframes and resources.
The PRINCE2 Delivery method and planning
The PRINCE2 planning techniques can be applied in both linear-sequential and iterative-incremental projects.
For linear-sequential projects, most planning effort is applied upfront in the processes of starting up a project and initiating a project.
Well-understood products and mature delivery activities often characterize these projects.
On the other hand, iterative-incremental projects focus on how much can be produced over a fixed period (such as a sprint or a timebox).
This is to deliver an initial product quickly and refine and improve it iteratively.
When an iterative-incremental approach such as agile is being used, a common planning approach would consist of:
- setting tolerances for each iteration that effectively fix time and cost and enable more flexibility in scope
- producing the project product description in terms of expected outcomes and benefits
- developing the user stories, epics, and product backlogs instead of product descriptions
- determining the length of releases or timeboxes and defining these as stages
- estimating the resource requirements for each stage and preparing the project budget
- Combine the product backlog and workflow in a collaborative planning tool like a Kanban board.
A Kanban board may be used instead of a team plan and is developed as a joint effort by the whole development team.
The iterative-incremental approach lends itself to the review and update of the plan as part of each cycle, just as in the preparation of stage plans in a linear project.
However, it reflects the updates in a collaborative planning tool.
Project Scale
The PRINCE2 planning technique supports a wide range of projects. Although product-based planning always applies, the level of effort involved in planning can easily be scaled up or down based on the characteristics and needs of the project.
If the products or delivery method is new to an organization, relying on experience or similar projects to capture requirements or estimate schedules and costs may be difficult.
Therefore, plans that incorporate a high degree of uncertainty and use risk-mitigating techniques (such as prototyping) or an iterative-incremental approach may be justified.
Describing products
The high-level requirements captured in the project product description are useful for management and direction purposes.
However, the delivery of the products requires more detail to enable realistic planning, estimating, scheduling, and quality control.
A description of a product’s purpose, format, composition, where it is derived from, quality specifications, and development responsibilities.
A product description captures the requirements for a product. It is produced when the need for the product is identified.
In linear-sequential projects, this is often performed during the initiation stage and then at stage boundaries for each subsequent stage.
However, in iterative, incremental projects, product descriptions evolve in parallel with product development work.
PRINCE2 Quality techniques
Although a wide range of quality techniques exist, the most used in a project context are:
Prototyping: produces an interim product that is used to obtain early feedback on its functionality or to understand full-scale production concerns and is integral to an iterative-incremental delivery method such as Agile, sometimes referred to as beta testing
Beta testing may also involve producing and using alternate versions of a product, such as in A/B testing, in which multiple versions are compared to determine the preferred one.
In a linear-sequential delivery method, there is generally more information about the required products and their delivery activities. This enables product descriptions and quality specifications to be developed in sufficient detail to support scheduling and estimation to a higher confidence level.
In iterative-incremental projects, the quality specifications and acceptance criteria are not fixed with the approval of the project initiation documentation.
Instead, they are considered goals to be achieved through iterations of development and delivery, often called sprints.
Understanding the types of quality techniques used and their timing, location, and resource requirements is essential to project planning.
In iterative-incremental projects, the quality specifications and acceptance criteria are not fixed with the approval of the project initiation documentation.
Instead, they are considered goals to be achieved through iterations of development and delivery, often called sprints.
In this case, the project product descriptions may be written as high-level user stories with associated acceptance criteria and can develop iteratively as the project proceeds.
Alternatively, the requirements (including quality specifications and acceptance criteria) can be captured and managed in a product backlog. This prioritized list is reviewed and updated with each iteration.
Acceptance criteria are commonly used to ascertain whether a user story has been completed.
An agile project may also aim for early delivery of a minimum viable product, a version of the product with just enough features to be usable, to provide feedback and refine requirements.
Developing a product description for the minimum viable product effectively demonstrates PRINCE2 principles with agile delivery.
The quality management approach may include a standard ‘definition of done’ and ‘definition of ready’.
Quality tolerances are not summarily defined at the stage or work package level but are defined as per product description within the plan’s scope.
Project risk
Defining context and objectives for risk management involves obtaining information about the project to ensure a common understanding of the specific objectives at risk and formulating an appropriate risk management approach.
The delivery method (linear-sequential, iterative-incremental, hybrid) will influence the project’s risk management approach.
The approach to managing risk must work with and support the project’s chosen delivery method. For example, a risk management approach that includes monthly risk review meetings will struggle to support an iterative-incremental delivery method with two-week sprints.
The PRINCE2 method does not require a particular format for risk management products or specific timings for risk management activities. They must be appropriate for the project’s format and pace.
For example, in an agile delivery method, risks in a risk register may be written on a whiteboard and reviewed during a daily stand-up meeting.
In this context, this manual approach may be just as valid as using a specialized IT system to capture and review risks.
It is also important to recognize that the project’s delivery method might work to mitigate or reinforce specific risks.
For example, an agile approach ensures that users do not overspecify requirements at the beginning of a project, which can be a risk in a more linear approach.
Although agile is characterized by a high level of engagement with the users directly involved in the project, it can lead to uncontrolled changes to the agreed baseline if not managed correctly.
Linear approaches reinforce the impression of ‘controlled change’ but can appear unresponsive and alienate users. It is of importance that the risk management approach recognizes these inherent differences.
Managing issues
The project manager should determine whether there are any organizational or external policies, standards, and procedures that must be applied and incorporate them into the project’s own issue management approach.
A key assumption underlying the choice of a linear-sequential approach to a project is that the number and magnitude of changes will be reduced as the project lifecycle progresses.
This is because it is generally much easier and less costly to change the project baseline early in the project.
For this reason, the issue management approach may propose tailoring tolerances to allow flexibility in early stages, such as during design, when the impact of changes may be relatively small.
Then, in later stages, such as during construction, the tolerances may be much more tightly restricted, and a larger portion of the change budget may be made available in recognition of the potential cost of even minor changes.
Issue management and change control are intrinsic to the iterative-incremental approach. The frequent review of progress and short cycles of delivery work (such as in agile methodologies) is intended to raise and resolve issues quickly.
This is to allow the scope baseline (sometimes referred to as the product backlog) to evolve in a manner that maintains close alignment between requirements and the product’s developed capabilities.
If the entire scope of the project’s delivery activities follows an incremental-iterative approach, it may be sufficient for the project manager to ensure that issues are consistently captured, assessed, and decided.
This would be in a manner that provides traceability back to the project product description and maintains an effective level of control.
In other cases, the project manager should consider structuring the issue management approach to allow the project board to retain change authority over management products.
Meanwhile, the authority over changes in features and functionality in specialist products should be delegated to the teams working within a framework such as PRINCE2 Agile.
The issue management approach may include the agile technique of trading/swapping features in response to issues to remain within tolerance.
Agile methods enable change late in the product development lifecycle to deliver a product that better matches user expectations with the biggest possible value. This philosophy applies when products are difficult to define in detail early in the project.
Project progress
It is important that the approach to managing progress complements and supports the project’s chosen delivery method rather than opposes it.
The implementation of ‘manage by exception’ efficiently uses senior management time, reducing their burden without removing their control. This ensures that decisions are made at the right level in the organization.
The goal is to alert the next management level in the project as early as possible that the work will move outside of agreed tolerances and a decision is needed on if and how to proceed.
The decision-maker can accept the deviation and its consequences or act to remove or reduce it.
For a project using an iterative-incremental delivery method, it will typically be more appropriate to focus on tracking how much of the requirement is being met by the end of the sprint rather than how long it will take to complete the products.
The tolerances would have been set in accordance with this. The frequent delivery of products that meet their acceptance and quality specifications is a primary source of progress information and provides the basis for forecasting future progress.
The formality of reporting may differ in an iterative-incremental project using agile techniques such as Kanban and burn-down or burn-up charts.
Checkpoint reporting may be based on a ‘pull’ system, where the project manager reviews the charts maintained by the development teams rather than being sent by them.
By contrast, for a project using a linear-sequential delivery method, the focus may be on when the stage’s products will be complete and for what costs. In this way, the project board can be confident that there is a robust basis to move from the current stage to the next.
Relevant reports and reviews should include lessons as the project progresses and at the end of each stage.
The goal is to seek improvement opportunities during the project’s life. The retrospective technique is an example of gathering lessons in an agile approach.
Highlight and checkpoint reports.
The project manager must provide the project board with summary information about the stage and the project’s status and distribute other information to the stakeholders at a frequency documented in the communication management approach.
Authorize a work package.
The degree of autonomy people require to deliver project work needs to be balanced with the need to coordinate the start and completion dates of work.
The vehicle for ensuring the coordinated timing of project work is the authorization, execution, and delivery of a work package.
For projects using an iterative-incremental delivery method, the work package description may be co-created by the team manager, development team, and product owner.
For projects using an iterative-incremental delivery method such as agile, the highlight report may be based on a ‘pull’ system, whereby the project board looks at progress charts being maintained by the project manager and development teams.
For projects using an iterative-incremental delivery method such as agile, the checkpoint report may be based on a ‘pull’ system, whereby the project manager looks at progress charts such as Kanban boards or burn-down charts being maintained by the team manager and development teams.
One to One PRINCE2 Coaching with Dave Litten
Step 1 – Talk to the PRINCE2 COACH
Before you join the course, talk to Dave directly. He can explain what is covered, how he can help you guarantee your PRINCE2 PASS. with Dave Litten as your very own personal PRINCE2 STUDY COACH
Step 2 – Join the PRINCE2 Coaching Program
Once you’ve spoken to Dave and have gotten a solid understanding of what Personal Coaching entails, click the button below to pay for your personal coaching.
Step 3 – Absorb the PRINCE2 Masterclass with your 1-to-1 PRINCE2 Mentor
Enjoy your personal one on one coaching with Dave Litten – PRINCE2 MENTOR. There will be only ONE outcome: Pass The Prince 2 Exam!
