PRINCE2-AGILE-PRACTITIONER Practice Questions

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 observation that the 'Staff Training Team gained more understanding of what to fix and what to flex' is a direct reflection on the effectiveness of the agile approach used in the project. The End Project Report is the formal document used during the 'Closing a Project' process to evaluate the project's performance, including how well the tailored PRINCE2 Agile method worked. The Agilometer is a tool used to assess the agile environment at the start and throughout the project. This observation provides a valuable lesson learned by reviewing the initial Agilometer assessment (which identified the team's unfamiliarity) against the final outcome, demonstrating the success of the training provided.

A. The end project report reviews performance against the Project Plan, not a granular summary of every timebox; that level of detail is for End Stage Reports.

B. The observation is about team learning and process improvement, not about handing over undelivered scope (Could Haves) to operations.

D. While the report does review delivered scope, this specific observation is about the team's capability and process maturity, not the quantity of features delivered.

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

Section 27.2.2

'Evaluate the project' activity: States that in the Closing a Project process

the project should be evaluated. "This includes assessing how well the project has gone against its Project Initiation Documentation... It also includes assessing the tailoring of PRINCE2 and the specific agile approaches used." This directly supports reviewing the agile ways of working.

Section 10.4

'Using the Agilometer': "It is good practice to review the Agilometer at the end of a project to see if the final situation was as expected." The scenario describes an initial assessment and a final observation

which constitutes this review.

Appendix A.1

'End Project Report': The purpose of the End Project Report includes reviewing "lessons learned". The observation about the team's improved understanding is a key lesson.

The communication is a simple, factual instruction directed at a large group of external stakeholders (30 vendors). Email is the most efficient and appropriate method to broadcast this information simultaneously to everyone. It provides a formal, written record for both the project and the vendors, which is crucial for logistical arrangements. Requesting confirmation of receipt creates a simple feedback loop to track that the message has been received and acknowledged, reducing the risk of miscommunication or vendors not showing up at the correct time.

A. Using visualizations is better suited for conveying complex spatial information, such as a site map or stall layout, not a simple time-based instruction.

C. Telephoning 30 individual vendors is highly inefficient and time-consuming. It also lacks an automatic written record, increasing the risk of disputes or misunderstandings.

D. A face-to-face workshop is impractical for gathering 30 external business owners and is unnecessary for a simple, non-negotiable directive that does not require collaborative discussion.

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

Section 18.3

'How to communicate': This section discusses the spectrum of communication richness. It states

"The richness of the communication needs to be appropriate to the situation." For broadcasting a simple

factual

and non-negotiable piece of information to a large external group

a less rich but more efficient and formal method like email is more appropriate than a high-bandwidth workshop or individual calls.

Section 4.3.1

'The PRINCE2 principle: Tailor to suit the project environment': The communication approach must be tailored. The environment here involves 30 external vendors. A scalable

formal

and auditable communication method like email is a suitable tailoring choice for this specific need.

Section 18.2

'The importance of communication': Effective communication ensures that "the right people get the right information at the right time". Emailing all vendors at once with a request for confirmation is the most effective way to achieve this for this specific scenario.

The 'Customer's Quality Expectations' section of the Project Product Description captures the high-level quality attributes the customer desires for the final product. It describes the overall characteristics of what "good" looks like from the customer's perspective. Option A, "There will be sufficient car parking for all event visitors and officials," is a broad statement of expectation. The other options represent specific, measurable details that would be defined later and documented as Acceptance Criteria, which are derived from these high-level expectations.

B. This is a specific, quantifiable requirement (50 spaces) that is better suited as a measurable Acceptance Criterion, not a general quality expectation.

C. This provides a detailed breakdown of parking space types, which is a design specification or a detailed Acceptance Criterion.

D. This is a precise technical specification or quality standard (dimensions), which is used to ensure the acceptance criteria are met, not a customer's quality expectation.

1. AXELOS. (2018). PRINCE2 Agile® Foundation and Practitioner. TSO (The Stationery Office).

Section A.21 Project Product Description: This appendix describes the components of the Project Product Description. It defines 'Customer's quality expectations' as "A description of the quality expected of the project product... They are captured in discussion with the customer." It explicitly states that these expectations are "used to derive the project’s acceptance criteria

" highlighting the distinction between the high-level expectation (Option A) and the specific

measurable criteria (Options B

C

and D).

Section 11.3.1 The Project Product Description (PPD): This section reinforces that the PPD should contain the customer's quality expectations

which are then refined into detailed acceptance criteria. The example of a website's quality expectation being "fast and easy to use" versus an acceptance criterion of "pages must load in under 2 seconds" illustrates the principle perfectly. Option A is analogous to the expectation

while the other options are analogous to the criteria.

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.

This approach is effective because it utilizes the daily stand-up, a core agile ceremony, as a mechanism for active risk management. By raising the risk, assigning an action to investigate it, and scheduling a report-back during this forum, the team ensures transparency and collective ownership. The daily stand-up is the appropriate venue for a delivery team to highlight and address impediments and risks that could impact their progress, enabling a rapid and collaborative response. This aligns with the PRINCE2 Agile behaviour of transparency and the agile concept of managing emerging issues on a daily basis.

A. While the business analyst is a suitable person to investigate, the strength of the approach is the use of the daily stand-up for team-wide visibility, not just the BA's specific role.

C. This reflects a command-and-control mindset. In an agile environment, the team is self-organizing, and any member can be assigned actions to help manage risks.

D. A risk being outside the project's direct control does not make it irrelevant. The project must still assess its potential impact and plan a suitable response.

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

Section 11.3.2

The Daily Stand-up: "The purpose of the daily stand-up is for the team to coordinate their work for the next 24 hours... It is also a good opportunity to raise any problems or impediments that may be affecting the team..." (p. 88). This establishes the stand-up as the correct forum for raising such issues.

Section 26.3.2

How agile helps to reduce risk: "Making progress and impediments visible on a daily basis allows for a rapid response." (p. 229). This directly links the daily visibility provided by stand-ups to effective risk management.

Section 8.3.2

The Team Manager: "The team manager role facilitates the team and protects them from outside distractions... They do not need to be involved in the detail of the work of the team on a day-to-day basis

as the team will self-organize..." (p. 67). This refutes the idea that the Team Manager must personally carry out all risk actions (Option C).

Section 26.3.1

Risk – an agile view: This section explains that agile embraces uncertainty and uses transparency to manage risk

making problems visible early. The scenario's approach is a direct application of this principle. (p. 228).

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 'Composition' section of a Project Product Description (PPD) is intended to list the major products or constituent parts that make up the final project product. Option A provides a detailed list of the components (e.g., data fields like 'team name', 'players' names') that form the 'Team Registration' feature. This statement describes what the feature is made of, which directly aligns with the purpose of the 'Composition' heading. The other options describe functional requirements, quality criteria, or user needs, which belong in other sections of the PPD, such as 'Acceptance Criteria' or 'Customer's Quality Expectations'.

B. This is a functional requirement describing a necessary capability. It is better suited for the 'Acceptance Criteria' section, which defines what the product must do to be accepted.

C. This is a non-functional requirement or a quality constraint. It should be recorded under 'Customer's Quality Expectations' or as a specific 'Acceptance Criterion'.

D. This is a user story that describes a user's need and its rationale. It is a source for requirements and acceptance criteria, not a list of product components.

---

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

Appendix A

Section A.21.2

Project Product Description: This section defines the purpose of each heading within the PPD. It states that 'Composition' is "A list of the major products to be delivered or created by the project." Option A is the only choice that provides a list of constituent parts

fitting this definition. In contrast

the manual defines 'Acceptance Criteria' as "A prioritized list of criteria that the project product must meet before the customer will accept it

" which is where options B

C

and D would more appropriately be captured.

Section 26.3.1

The project product description: This section reinforces that the PPD defines the project's scope and what will be delivered. The breakdown of a feature into its core components

as in option A

is a way of defining a part of that scope within the product's composition.

The primary purpose of the Agilometer is to assess the agile environment and identify key risks. The results show a very low score of '2' for the 'Level of Collaboration', which is a significant risk for any agile endeavor. The PRINCE2 Agile guidance specifically suggests that a low score in this area may be due to a 'blame culture' or because team members have had negative experiences with teamwork in the past. Therefore, the most appropriate and insightful observation is to identify this critical weakness and the need to investigate its root cause. Option D directly addresses this by proposing an investigation into a potential cause explicitly mentioned in the official guidance.

A. This is directly contradicted by the high score of '5' for 'Flexibility on what is delivered', which indicates there is significant tolerance regarding project scope.

B. The official PRINCE2 Agile guidance explicitly warns against relying on an average or total score, as this can mask a single, critical area of weakness like the low collaboration score.

C. The Agilometer has successfully fulfilled its purpose by highlighting a significant risk. There is no information in the scenario to suggest the tool itself is flawed or needs to be changed.

AXELOS

"PRINCE2 Agile®" (2015).

Section 11.4.2

"Slider 2: Level of collaboration": This section explains the implications of the collaboration score. It states

"A low score may indicate a 'blame culture' or that people have been 'let down' by team-working in the past." This directly supports the validity of the investigation proposed in option D.

Section 11.3

"How to use the Agilometer": This section clarifies the tool's purpose. It states

"It is not appropriate to add up the scores and create a total... as this can hide an area of major concern." This reasoning directly invalidates option B

which relies on an average score.

Section 11.3

"How to use the Agilometer": The guidance also states

"The project manager would then look at the areas of weakness and decide what

if anything

to do about them." This supports the approach of focusing on the low collaboration score

as done in option D.

This approach is a prime example of an agile feedback loop. By showing rough drawings (a form of low-fidelity prototype) to other staff, the team is seeking early and frequent feedback from potential users. This feedback is crucial for clarifying requirements and understanding what is most valuable. In an agile context, change is managed by continuously incorporating such feedback to ensure the final product is fit for purpose. This allows the team to prioritize the essential elements for delivery within the current timebox, adapting their plan based on what they learn.

A. While changes within a timebox might not affect the project baseline, this is a procedural point. The primary value of the approach is gathering feedback to make informed decisions, not its impact on baselines.

C. This statement is incorrect. The proposed informal approach is a form of exploration and can foster a creative and honest feedback environment, which is a positive agile behaviour for enabling change.

D. Moving pages to the next timebox is a potential outcome of the feedback, not a reason the feedback process itself is poor. The feedback is necessary to make an informed decision on how to proceed.

---

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

Section 12.3.5

Page 89: "Agile sees change as a normal part of the process... The important point is that change is managed and controlled... The feedback loop is a central part of this process." This supports the idea that feedback is the core mechanism for managing change in agile.

Section 26.4.2

Page 223: Discusses the use of prototypes

stating

"A prototype is an excellent way to get feedback on a product... It is a form of rich communication and is very collaborative." The 'rough drawings' in the scenario serve as a prototype.

Section 4.3.3

Page 27: Describes the PRINCE2 Agile behaviour of 'Rich communication'. The proposed face-to-face interaction in the cafeteria with visual aids (drawings) is a clear example of this behaviour in practice to facilitate understanding and feedback.

Section 11.2.6

Page 79: Under the principle 'Learn from experience'

it states

"Feedback is a vital ingredient for any project... Agile has this built in with its use of feedback loops." This reinforces that the proposed action is a fundamental agile practice.