Free PRINCE2-AGILE-PRACTITIONER Practice Test

The scenario involves multiple work streams (Marketing, Website, Event Village, Staff Training) operating concurrently. The Website Team's Scrum Master is concerned about project-level issues and inter-team dependencies that could impact their progress. A 'Scrum of Scrums' is a scaled agile technique specifically designed to coordinate the work of multiple teams. Representatives from each team meet to discuss progress, integration points, and impediments that affect more than one team. This provides the necessary project-level visibility to identify and address cross-team issues, which is a key activity for the Project Manager during the 'Controlling a Stage' process.

B. Retrospectives: This is a team-level ceremony focused on improving a single team's internal processes and ways of working, not for coordinating across multiple teams.
C. MoSCoW: This is a prioritization technique used to rank requirements (Must, Should, Could, Won't). It does not address inter-team communication or issue identification.
D. User stories: These are a format for describing requirements from a user's perspective. They represent work to be done, not a method for project-level coordination.

AXELOS

"PRINCE2 Agile®" (2015)

Section 26.3.4

Scrum of Scrums

Page 218: "The purpose of the Scrum of Scrums is to coordinate the work of multiple teams... Each team would send a representative... to report on their team’s progress

any plans for the upcoming day and any impediments that are blocking their team’s progress." This directly addresses the need for cross-team coordination to identify issues.

AXELOS

"PRINCE2 Agile®" (2015)

Section 14.4.2

Reviewing the stage status

Page 112: In an agile context

the Project Manager reviews progress by attending key meetings. The Scrum of Scrums is a primary meeting for gaining an overview of progress and issues across multiple teams

which is central to the 'Controlling a Stage' process.

The scenario highlights significant uncertainty within the Marketing Team regarding the most effective channels and priorities. The proposal to shorten stages to a weekly cycle directly addresses this risk. By aligning stage boundaries with the weekly releases, the Project Board can frequently review the actual performance of the marketing activities. This creates a tight feedback loop, allowing for rapid decisions to either continue, pivot, or stop a particular approach. This embodies the agile concept of 'fail-fast and learn-fast', ensuring that the project's resources are directed towards the most valuable activities based on empirical evidence rather than assumptions. In a high-uncertainty environment, this is an effective application of the 'manage by stages' principle.

A: Inter-team collaboration is facilitated by agile ceremonies like daily stand-ups within a stage, not by the formal Project Board review that occurs at a stage boundary. C: A management stage can contain multiple timeboxes or sprints. There is no PRINCE2 Agile rule stating that a new stage must begin with every new timebox. D: While the official guidance suggests typical stage lengths, PRINCE2 Agile emphasizes tailoring. Ignoring the specific context of high uncertainty in favor of a general guideline would be poor practice. ---

1. Axelos. (2015). PRINCE2 Agile®. TSO (The Stationery Office).

For Correct Answer (B): Section 10.2.2 explains that a key aspect of agile is to "learn fast and fail fast". Section 12.3.1 discusses tailoring stage length

noting that while very short stages can create overhead

the appropriate length is a balance. In a context of high uncertainty

tailoring for more frequent control points to enable rapid learning is a valid application of the principle.

For Incorrect Option (A): Chapter 15

"Communication"

details that collaboration is handled through techniques like Information Radiators and Daily Stand-ups

which are separate from the governance function of stage boundaries.

For Incorrect Option (C): Figure 12.1 in Section 12.3 clearly illustrates that a management stage typically contains multiple sprints/timeboxes

showing they are not required to be aligned on a one-to-one basis.

For Incorrect Option (D): Section 12.3.1 provides guidance that stages of "two to four weeks may be appropriate" for a project of a few months but stresses this is a guideline to be balanced against the project's specific context and need for agility.

The scenario describes a situation where the relationship between cause (social media promotion) and effect (increased health and fitness) is not predictable and can only be understood in retrospect. The proposed action is to review early communications to identify the effect and the reasons for it, which will then inform future initiatives. This approach of experimenting, observing the outcome, and then responding is the 'Probe-Sense-Respond' model, which is the defining characteristic of the Complex domain within the Cynefin framework. This domain is appropriate for situations with "unknown unknowns" where emergent practices are required.

A. Chaotic: This is incorrect because the situation is not a crisis. There is no turbulence requiring immediate action to establish order; rather, there is an underlying relationship to be explored.
B. Obvious: This is incorrect because the cause-and-effect relationship is not clear or self-evident. If it were obvious, the effect could be easily predicted and measured from the start.
D. Disorder: This is incorrect because the project manager is actively assessing the situation using the Cynefin framework, not in a state of confusion about which domain applies. ---

1. AXELOS. (2015). PRINCE2 Agile®. TSO (The Stationery Office).

Section 10.2.3

The complex domain: "The relationship between cause and effect can only be perceived in retrospect... The approach is to Probe–Sense–Respond... We conduct experiments that are safe to fail... and use the results to inform our next steps." This directly maps to the scenario's description of reviewing early results to understand their effect and inform future work.

Section 10.2.1

The obvious domain: Describes situations where cause and effect are clear to all

using a 'Sense–Categorize–Respond' approach

which is contrary to the uncertainty described in the scenario.

Section 10.2.4

The chaotic domain: Describes situations with no relationship between cause and effect

requiring an 'Act–Sense–Respond' approach to impose order

which is not relevant here.

Figure 10.1

The Cynefin framework: Visually represents the domains and their corresponding management models

reinforcing the distinction between Complex (Probe-Sense-Respond) and the other domains.

The requirement for the event to be "fully accessible to all visitors" is a high-level, non-functional requirement that defines a critical quality characteristic for the entire project outcome (the tournament). According to PRINCE2, such overarching quality attributes are formally captured in the Project Product Description (PPD). The 'Customer's Quality Expectations' section of the PPD is the specific place to record these key quality requirements from the customer's (the LGA's) perspective. This ensures the quality standard is defined at the project level and guides the development of all constituent products.

A. The 'composition' heading of a Project Product Description lists the major products that make up the final outcome, not its quality characteristics.
C. A burn chart is a progress-tracking tool used to visualize work remaining over time; it is not used for recording requirements.
D. While accessibility features would be detailed in user stories, this overarching, project-wide mandate is best recorded as a quality expectation in the PPD first. ---

1. AXELOS. (2018). PRINCE2 Agile® Guidance. TSO (The Stationery Office).

Section 10.3.1

Project Product Description: "The Project Product Description is a special form of Product Description that defines what the project must deliver in order to gain acceptance... It includes... the customer’s quality expectations..." This confirms the PPD is the correct location.

Appendix A

Section A.7

Project Product Description: The template for the PPD explicitly includes a section for "Customer's quality expectations

" described as "A description of the quality expected of the project’s product and the standards and processes that will need to be applied." This directly supports recording the accessibility standard here.

2. AXELOS. (2017). Managing Successful Projects with PRINCE2® 6th Edition. TSO (The Stationery Office).

Section 7.3.1

Create the Project Product Description: "The Project Product Description is created in the Starting up a Project process as part of the initial scoping activity... It should include... the customer’s quality expectations." (p. 68).

Appendix A

Section A.21

Project Product Description: The template defines the 'Composition' section as "A list of the major products to be delivered

" which contrasts with the purpose of the 'Customer's quality expectations' section

reinforcing why option A is incorrect. (p. 367).

The requirement for water pressure is a non-functional requirement (NFR) as it defines a quality characteristic ('how well') of a feature, rather than the feature itself ('what'). According to PRINCE2 Agile guidance, NFRs should not be captured as standalone technical stories. Instead, they should be integrated directly into the relevant user stories as acceptance criteria. For instance, a user story like, "As a player, I want to use a shower..." would have acceptance criteria specifying the required water pressure. This approach ensures that quality is testable and intrinsically linked to the functionality being delivered, preventing it from being overlooked.

A. A product's performance (an NFR) should be an acceptance criterion for a user story, not a standalone technical story, to link it directly to user value.
B. While an NFR might apply to multiple stories (in which case it could be part of the Definition of Done), recording it as a technical story is incorrect.
D. This statement is too vague. NFRs are indeed quality criteria, but PRINCE2 Agile specifically recommends documenting them as acceptance criteria within user stories for clarity and testability.

1. AXELOS. (2015). PRINCE2 Agile®. TSO (The Stationery Office).

Section 11.3.2.2

Page 91: "Acceptance criteria are a list of items that are used to confirm that a user story has been completed... They are often related to non-functional requirements such as performance

usability

security etc." This directly supports integrating NFRs into user stories.

Section 11.4.2

Page 94: "The quality criteria for a product are ultimately expressed as acceptance criteria for the requirements that relate to that product." This reinforces that NFRs (quality criteria) should be part of the requirements (user stories).

Section 23.2.2

Page 201: Discusses that non-functional requirements can be handled as specific acceptance criteria on a user story or

if they apply to many stories

as part of the Definition of 'Done'. It does not advocate for creating separate technical stories for NFRs.

The most appropriate response is to reschedule the combined course. The 'Health and Safety' training is a 'Must Have', while the 'healthy eating' training is a 'Should Have'. A quality check delay of three days is affecting the 'Should Have' component. Rescheduling the entire combined course by a few days allows for the quality criteria to be met for all materials, ensuring the full planned scope and benefit of the work package is delivered. This decision is pragmatic, assuming the minor delay is within the work package's time tolerance and does not impact the project's final deadline. It prioritizes delivering the complete, quality-checked product over rigidly adhering to an intermediate schedule for a part of it.

A. De-scoping the 'Should Have' training sacrifices planned benefits. This action is typically taken only when a fixed deadline is at risk, which is not stated to be the case here.
C. Removing the requirement from the Project Product Description is a formal change control matter for the Project Board. It is an excessive response to a minor, short-term scheduling issue.
D. Using unchecked materials violates the fundamental PRINCE2 principle of 'Focus on products' and their associated quality criteria. Quality is not a variable to be compromised.

1. AXELOS. (2015). PRINCE2 Agile® Guidance. The Stationery Office (TSO).

Section 10.3

Tolerances: This section explains that work should be managed within set tolerances. A minor rescheduling of a work package

if it does not cause a breach of stage or project tolerance

is an acceptable action for a team to take. This supports option B as a valid decision within the framework.

Section 7.1

The PRINCE2 principles: continued business justification: Option B aims to deliver the full planned benefits from both user stories. This better upholds the business justification compared to Option A

which sacrifices the benefits of the 'Should Have' requirement.

Section 7.5

The PRINCE2 principles: focus on products: This principle emphasizes that products must meet their quality criteria to be considered complete. Option D violates this directly. Option B upholds this by waiting for the quality check to be completed.

Section 11.3.1

MoSCoW: While MoSCoW allows for de-scoping 'Should Have' items (as in Option A)

this is primarily to protect a fixed deadline. If the deadline is not threatened by a minor delay

delivering the full scope (including 'Shoulds') is preferable.

The fundamental reason for 'blending and weaving' PRINCE2 with agile is to create a symbiotic relationship between project governance and product delivery. PRINCE2 provides the robust framework for project direction and management (control), while agile empowers delivery teams with the autonomy to self-organize, iterate, and respond to change. This integration allows for agile flexibility at the delivery level to flourish within the controlled, structured environment that PRINCE2 establishes for the project as a whole. It addresses the common challenge of maintaining governance while enabling the benefits of agile ways of working, thus achieving the "best of both worlds."

A. Adjusting a 'command and control' culture is a potential outcome, but the primary reason is to integrate agile delivery within a controlled project structure, not just to change culture.
B. This describes an agile principle (focus on value over scope), but it's a specific technique or mindset, not the overarching reason for the integration itself.
D. This is a factual statement defining the relationship between the frameworks, but it does not explain the reason or purpose for combining them in a project. ---

1. AXELOS. (2015). PRINCE2 Agile®. TSO (The Stationery Office).

Section 4.1

The rationale for blending PRINCE2 and agile: "How do you get the control and governance from PRINCE2 and the agility from the agile way of working? PRINCE2 Agile has been created to provide the answer to this." This directly supports the synthesis of control and agility (self-organization).

Section 4.3.1

PRINCE2 and agile can work together: "PRINCE2 works at the directing and managing level... Agile works at the delivery level... PRINCE2 Agile provides the missing link and explains how to put the two together." This reinforces the concept of combining management control with delivery team autonomy.

Figure 4.1

The two layers of PRINCE2 Agile: This diagram visually represents PRINCE2 providing the 'management/direction' layer and agile providing the 'delivery' layer

illustrating the blend of control and self-organization.

The core issue is a stakeholder perception problem: local residents fear they will bear the event's costs. This is a direct contradiction to the project's primary constraint of being self-funded through sponsorship and fees. The most effective way to counter this concern is through transparent communication that directly addresses the funding model. Publishing a list of sponsors provides clear, tangible evidence that the project has secured external funding, thereby reassuring the public that taxpayer money is not at risk. This aligns with the PRINCE2 Agile behaviour of transparency, which involves making relevant information visible and easy to understand for all stakeholders.

A. A points system is an internal agile estimation technique for effort, not a financial report. Publishing this would be confusing and meaningless to the public and would not address their financial concerns.
C. Burn-charts are internal project management tools that track the rate of work completion. They do not provide information about project funding or costs, making them irrelevant to the public's specific concern.
D. A release review at the end of stage 4 is too late. The negative perception exists now, and waiting until the event is about to happen would fail to manage this important stakeholder risk proactively.

AXELOS

"PRINCE2 Agile® Foundation and Practitioner" (2021)

Section 5.2.1

Transparency: "This is not just about being open and honest

but also about making information easy to find... Transparency is a key ingredient in creating trust..." Publishing sponsor lists is a direct application of this behaviour to build trust with the public.

AXELOS

"PRINCE2 Agile® Foundation and Practitioner" (2021)

Section 12.1

Introduction to communication: Effective communication is vital for stakeholder engagement. The chosen communication method must be appropriate for the audience. Publishing sponsor lists is an appropriate method for the general public

whereas burn-charts (Option C) are not.

AXELOS

"PRINCE2 Agile® Foundation and Practitioner" (2021)

Section 12.4

PRINCE2 Agile guidance on the communication theme: "Information should be radiated... so that it can be seen by anyone who is interested." This supports the proactive and public nature of the action described in option B.

The PRINCE2 Agile target to 'embrace change' is about being responsive to new information to deliver a more accurate and valuable product. The team manager's actions are a prime example of this. By identifying the incorrect assumption, clarifying the actual training needs with a customer representative, and immediately updating the backlog, the manager ensured the change was incorporated positively. This action directly leads to a more accurate and fit-for-purpose training delivery, which is the fundamental goal of embracing change rather than treating it as a problem.

B. While visualization is a useful agile technique, the core reason for compliance is the act of positively incorporating the change to improve the outcome, not the specific communication method used.
C. This is an unsubstantiated criticism. The scenario states a "customer representative" was involved, which is an appropriate role for this type of clarification. The focus is on the positive reaction to change.
D. This contradicts the agile principle of emergent requirements. The Project Product Description is high-level; detailed requirements and acceptance criteria are expected to be refined throughout the project.

AXELOS. (2015). PRINCE2 Agile® Guidance. TSO (The Stationery Office).

Section 4.3.6

The six PRINCE2 Agile targets: This section introduces the target 'Embrace change'

explaining that change is seen as a positive that helps to deliver a more accurate final product. The scenario demonstrates this by using new information to correct the training plan.

Section 11.3.1

Reacting to change: This section states

"Change is not seen as a problem in an agile context; it is seen as a positive step that helps to create the right product." The team manager's actions align perfectly with this principle.

Section 23.1

The purpose of the Requirements theme [in an agile context]: This section clarifies that requirements are not fixed at the start but are refined over time. This supports why option D is incorrect

as waiting for perfect upfront specifications in the Project Product Description is not an agile approach.

A burn-down chart visually represents the amount of work remaining over time. In agile environments like Scrum, this chart is typically updated daily. The total work remaining is recalculated based on the team's estimate of the effort left to complete all tasks. For a five-day task where four days of work have been completed, one day of effort remains. This means 80% of the estimated work is complete. The chart would be updated to reflect that four days of work have been 'burned' from this task's contribution to the total. Option B, while using the term '% complete' which is often avoided, is the only choice that accurately reflects this incremental tracking of progress.

A. This calculation is illogical. The difference between work completed (4 days) and work left (1 day) is 3 days, which does not represent the work remaining.
C. "Almost complete" is a subjective and unquantifiable status. A burn-down chart requires a numerical value representing the amount of work remaining to be plotted accurately.
D. This suggests waiting until a task is 100% finished before updating the chart. This contradicts the standard practice of daily updates to reflect actual progress and re-estimated remaining effort.

AXELOS. (2015). PRINCE2 Agile®. The Stationery Office.

Section 23.3.2.1 'Burn-down charts': "A burn-down chart shows the amount of work remaining over time... At the end of each day (or a similarly appropriate time period) the amount of work remaining is calculated and plotted on the chart." This supports the principle of daily

incremental updates based on remaining work

which contradicts option D and supports the logic behind option B.

Section 23.3.2.1: The vertical axis of a burn-down chart is explicitly defined as "Amount of work remaining". When 4 of 5 days are done

the remaining work is 1 day. This is equivalent to stating the task is 80% complete in terms of effort expended. Options A and C do not represent a quantifiable amount of work remaining.