PRINCE2 PRINCE2-Agile-Foundation PRINCE2 Agile Foundation (Version 2) Exam Exam Practice Test

Agile Foundation guidance emphasizes building quality into the product from the very beginning rather than relying on late-stage inspection or escalation. When a minor quality control failure occurs during product creation, the most appropriate initial response is to revisit the development and test activities, making option C the correct answer. Agile promotes continuous quality assurance through iterative development, frequent testing, and fast feedback loops, allowing teams to correct issues as soon as they emerge.

In Agile environments, quality is a shared responsibility of the entire team. Minor defects or quality issues are viewed as learning opportunities rather than failures that require formal escalation. Revisiting development and testing activities allows the team to quickly identify root causes, such as unclear acceptance criteria, gaps in automated tests, or misunderstandings in requirements. By addressing the issue at its source, teams can prevent similar defects from recurring in future iterations.

Option A, escalating the issue to the project manager, is generally unnecessary for minor quality failures in Agile. Agile teams are empowered to self-manage and resolve issues at the team level whenever possible. Option B, performing an independent review, may be appropriate for major or systemic quality problems but is excessive as an initial response to a minor issue. Option D, discussing the issue with the chief product owner, is also not the first step unless the issue affects product value or requires a change in priorities.

Agile Foundation documents stress the importance of continuous improvement, built-in quality practices, and early defect resolution. Techniques such as test-driven development, continuous integration, peer reviews, and frequent retrospectives support this approach. By immediately revisiting development and test activities, Agile teams maintain flow, reduce rework, and ensure that quality issues are resolved quickly and effectively, reinforcing Agile principles of transparency, inspection, and adaptation.

Kanban uses a flow-based approach to visualize and control work in progress (WIP). It emphasizes limiting WIP to improve flow and reduce bottlenecks, with continuous monitoring via Kanban boards. This approach supports flexibility, transparency, and efficiency in managing tasks.

The Agilometer (A) measures agility, Lean (B) is a broad philosophy focusing on waste reduction, and Scrum (D) is an iterative framework but uses time-boxed sprints rather than flow-based control.

Agile Foundation guidance, aligned with PRINCE2 Agile concepts, explains that integrated elements are used to describe different aspects of how a project is structured and delivered. Among these elements, the “people” element specifically defines who is working on the project and who is affected by the project, making option D the correct answer.

The people element focuses on roles, responsibilities, relationships, and stakeholders involved in the project. It identifies not only the delivery team members but also sponsors, users, customers, suppliers, and any individuals or groups impacted by the project’s outcomes. Agile and PRINCE2 Agile both emphasize that successful delivery depends heavily on people, collaboration, and clear accountability. Understanding who is involved and affected ensures effective communication, engagement, and decision-making throughout the project lifecycle.

Option A, the project context, describes the environment in which the project operates, including organizational, regulatory, and external factors, but it does not specifically define who is involved. Option B, the PRINCE2 practices, focuses on areas such as risk, quality, plans, and progress, providing guidance on what needs to be managed rather than who is involved. Option C, the PRINCE2 processes, outlines the flow of activities and decision points during the project, not the people performing or impacted by them.

Agile Foundation documents stress that Agile delivery is people-centric. Self-organizing teams, empowered roles, and active stakeholder involvement are core to Agile success. The people element supports this by ensuring clarity around roles, expectations, and collaboration pathways. By clearly defining who is working on the project and who is affected by it, teams can build trust, manage stakeholder needs effectively, and adapt to change more smoothly. This alignment of people with purpose and value delivery is central to both Agile principles and PRINCE2 Agile integration.

Personas in PRINCE2 Agile serve as fictional, archetypal users representing the needs, behaviors, and goals of real users. In the business case practice, personas are used to identify and articulate specific user benefits. This ensures the project focuses on delivering value that meets the actual needs of different user groups.

By understanding personas, teams can tailor product features and prioritize requirements that provide meaningful benefits, thereby strengthening the business case and increasing stakeholder buy-in. Personas help clarify who will use the product, what problems they face, and how the solution delivers value.

Personas go beyond demographic grouping (A); they are detailed profiles including motivations and pain points. They do not relate directly to timelines (B) or product version differentiation (D).

Using personas aligns with agile principles of customer focus and continuous stakeholder engagement embedded in PRINCE2 Agile.

The Progress Review Workshop is the key forum to assess the current status of the project and address challenges or issues affecting progress. It typically involves reviewing the current stage or release against plan, assessing risks, issues, and dependencies, and agreeing on corrective actions or decisions to keep the project on track.

While retrospectives (B and C) focus on reflecting and improving team practices, and team planning (A) looks ahead to upcoming work, progress reviews are focused on monitoring, control, and decision-making at the project or stage level.

This workshop aligns with PRINCE2’s principle of manage by exception, enabling timely interventions without unnecessary escalation.

The Risk practice is specifically aimed at controlling uncertainties that could impact the achievement of the project’s objectives. In PRINCE2 Agile, risk management involves identifying, assessing, and controlling threats and opportunities to reduce negative impacts and maximize positive outcomes.

Effective risk management is a core theme and practice in PRINCE2 Agile and is crucial for agile environments where change and uncertainty are inherent. The practice ensures that risks are continuously monitored and appropriate responses are planned and implemented. This proactive management helps keep the project viable and aligned with business justification.

While plans support managing scope and resources, issues deal with current problems rather than potential future events, and quality ensures that products meet requirements, risk management uniquely focuses on uncertainty.

The PRINCE2 Agile guidance emphasizes integrating agile techniques such as frequent reviews and retrospectives to improve risk awareness and control.

When blending PRINCE2 with agile, adopting an agile mindset is the most important factor for success. The mindset involves embracing agile values such as flexibility, collaboration, delivering value incrementally, and being responsive to change. Without this cultural and attitudinal shift, the use of agile techniques or processes becomes superficial and fails to deliver the benefits of agility.

PRINCE2 is a highly structured project management method with defined roles, processes, and controls. Integrating agile methods requires more than just overlaying practices like Scrum or Kanban; it demands a fundamental shift in thinking about leadership, governance, team dynamics, and customer involvement.

Fostering psychological safety (B) is indeed important because it allows teams to express ideas, take risks, and innovate without fear of negative consequences. However, this psychological safety is a component of the broader agile mindset.

Using agile techniques (C) and following processes (D) are enablers but do not guarantee agile success. Teams may mechanically perform ceremonies without understanding the principles behind them.

The PRINCE2 Agile guidance emphasizes that the mindset must permeate all levels of the project and organization. Leaders and teams should adopt agility as a philosophy, not just a set of practices.

The Agile Enablement Workshop provides a collaborative environment where teams and stakeholders define critical agile artifacts, including the Definition of Ready. This definition specifies the criteria a user story or product backlog item must meet before work can begin, ensuring clarity and readiness.

The workshop facilitates alignment on quality standards, scope, and expectations, reducing ambiguity and improving flow through development cycles. By involving all key participants, the Definition of Ready is meaningful and practical, tailored to the project's specific context.

While starting up (A), kickoff (B), and initiation workshops (C) focus on project foundation and planning, they do not specifically focus on agile readiness criteria.

This workshop is essential for embedding agile practices within PRINCE2 governance and fostering effective delivery.

In Agile Foundation guidance, the team coach plays a key role in supporting one or more Agile teams in adopting and improving Agile ways of working. A core responsibility of the team coach is to liaise with the agile coach, making option A the correct answer. This relationship ensures alignment between team-level coaching and organization-wide Agile adoption.

The team coach focuses primarily on the day-to-day effectiveness of the team. This includes helping the team understand Agile principles, improve collaboration, enhance communication, and continuously improve their ways of working. The agile coach, on the other hand, typically operates at a broader level, supporting multiple teams, leaders, and the organization as a whole in embedding Agile culture and practices. By liaising with the agile coach, the team coach ensures that insights, challenges, and progress at the team level are shared and addressed consistently across the organization.

Option B, liaising with the project manager, is not a primary responsibility of the team coach in Agile foundations. While coordination may occur, Agile reduces dependency on traditional command-and-control roles. Option C, liaising with the chief product owner, is also not central to the team coach role, as product ownership focuses on value and prioritization rather than team dynamics and Agile maturity. Option D, liaising with project assurance, aligns more with governance and compliance functions rather than coaching responsibilities.

Agile Foundation documents emphasize that effective coaching relies on collaboration between coaching roles. The team coach provides detailed, practical feedback from the team, while the agile coach offers strategic direction, consistency, and organizational support. This collaboration strengthens Agile adoption, helps remove systemic impediments, and ensures that teams are supported both locally and at scale. By liaising with the agile coach, the team coach helps create a coherent, sustainable Agile environment focused on continuous improvement and value delivery.

PRINCE2 Agile was specifically developed to address the challenge of applying Agile approaches within large, complex, and highly governed environments. Agile frameworks are highly effective at the team level, but Agile Foundation materials recognize that organizations often struggle when attempting to scale Agile across multiple teams, complex dependencies, regulatory constraints, and formal governance structures. This makes option B the correct answer.

Agile frameworks such as Scrum or Kanban focus on small, empowered teams delivering value iteratively. However, when initiatives become larger—spanning multiple teams, suppliers, and organizational units—challenges arise around coordination, assurance, reporting, and decision-making. Senior stakeholders often still require visibility, control, and confidence around investment, risk, and progress. PRINCE2 Agile bridges this gap by combining Agile delivery techniques with the governance, roles, and controls provided by PRINCE2.

Option A is incorrect because Agile frameworks are designed to be flexible rather than rigid. Option C is also not the primary challenge addressed by PRINCE2 Agile, as most Agile frameworks clearly define core roles, even if they differ from traditional roles. Option D is incorrect because Agile frameworks are explicitly designed to be combined with other methods, which is one of Agile’s strengths.

Agile Foundation documents explain that PRINCE2 Agile enables organizations to “blend” Agile delivery with project management governance. It allows Agile teams to work iteratively while ensuring alignment with business objectives, risk management, and stage-based oversight. By providing guidance on how to tailor governance without constraining agility, PRINCE2 Agile supports scaling Agile in complex environments. This makes it particularly valuable for organizations transitioning to Agile while still needing structure, assurance, and control at the enterprise level.

In Agile Foundation guidance, the risk practice is explicitly responsible for the identification, assessment, and management of uncertainties, making option A the correct answer. Risk is defined as uncertainty that, if it occurs, will have a positive or negative impact on objectives. Agile recognizes that uncertainty is inherent in complex and adaptive work, so effective risk management is essential to successful delivery.

The risk practice focuses on proactively identifying uncertainties early, assessing their likelihood and impact, and determining appropriate responses. Agile Foundation documents emphasize that risk management in Agile is continuous rather than a one-time activity. Risks are regularly reviewed, updated, and addressed throughout the lifecycle as new information emerges. This aligns with Agile principles of transparency, inspection, and adaptation, allowing teams to respond to uncertainty in a timely and informed manner.

Option B, plans, focuses on outlining how objectives will be achieved and how work will be organized over time. While planning may take risks into account, it does not primarily identify or assess uncertainties. Option C, quality, ensures that outputs meet agreed standards and acceptance criteria but does not deal directly with uncertainty. Option D, business case, justifies why a project should proceed by outlining costs, benefits, and risks at a high level, but it does not actively manage or assess uncertainties on an ongoing basis.

Agile Foundation guidance highlights that Agile approaches often reduce risk by delivering incrementally, seeking early feedback, and validating assumptions quickly. However, this does not eliminate the need for a structured risk practice. Instead, risk management supports Agile delivery by making uncertainties visible and manageable. By embedding risk identification and assessment into regular team activities, organizations can make better decisions, protect value, and increase confidence among stakeholders while still maintaining flexibility and responsiveness to change.

Reference https://publications.axelos.com/prince2agile2016/content.aspx?page=pra_126 &showNav=true&expandNav=true

The Delivering level is responsible for the day-to-day management and decision-making within the constraints set by the project manager. Delivering teams carry out the actual work to create the project products and manage their activities under the project’s governance framework. The Project Manager manages the overall project, while directing sets the strategic direction and commissioning authorizes initiation.

This separation ensures clear responsibilities and empowers the delivery teams to self-manage within defined boundaries.

The Project Backlog is the artifact used to describe the project’s major products in the form of epic user stories. Epic stories are large, high-level user stories that capture significant features or product components that may later be decomposed into smaller, more detailed user stories in the product backlog.

The Project Backlog provides a strategic view of what the project intends to deliver and supports planning at the project level, including releases and stages. It bridges the gap between business requirements and team-level delivery.

The Product Backlog (C) contains detailed user stories ready for development but is typically more granular. The Release Map (B) plans releases and iterations but does not list epic stories. The Project Dashboard (A) is a reporting tool, not a repository of requirements.

The use of epic user stories in the project backlog aligns with agile practices for managing scope and enables incremental delivery aligned with business priorities.

Agile Foundation guidance explains that the risk practice is concerned with identifying, assessing, and managing uncertainty in a structured and proactive way. One of the specific ways this practice is applied in Agile and PRINCE2 Agile contexts is by identifying Agile adoption risks using the Agilometer, making option A the correct answer.

The Agilometer is a diagnostic tool designed to assess how suitable Agile approaches are for a particular project or environment. It examines factors such as organizational culture, stakeholder engagement, governance requirements, team capability, and delivery constraints. By highlighting areas of risk related to Agile adoption, the Agilometer enables teams and leaders to make informed decisions about how Agile should be tailored and what mitigations are needed. This aligns directly with the purpose of the risk practice, which is to reduce uncertainty and protect value.

Option B, trading to handle emerging changes, relates to scope and prioritization flexibility rather than risk management itself. While trading can reduce risk indirectly by controlling scope, it is not a primary application of the risk practice. Option C, using an objectives and key results framework, focuses on goal-setting and performance measurement, not risk identification or assessment. Option D, identifying criteria in the Definition of Done, supports quality management rather than risk management.

Agile Foundation documents emphasize that Agile does not eliminate risk; instead, it makes risk visible and manageable through early feedback, incremental delivery, and structured assessment. The risk practice ensures that uncertainties are understood and addressed continuously throughout the lifecycle. By using tools such as the Agilometer, organizations can anticipate challenges in Agile adoption and take proactive steps to manage them. This supports effective governance while preserving Agile’s flexibility, ensuring that Agile is applied in a way that is both realistic and sustainable.

The starting-up workshop is the initial workshop where the foundation for the project is established, including the creation and clarification of project role descriptions. Defining roles early ensures clarity of responsibilities, helps establish governance, and sets expectations for the project team.

Kickoff (B) focuses on launching the project, initiation (C) develops detailed plans, and the project canvas (D) is a tool for capturing high-level information but does not define roles explicitly.

A key benefit of being and doing agile is increasing user satisfaction by delivering value early and continuously, adapting to feedback, and ensuring the product meets real user needs. Agile approaches emphasize collaboration with customers and iterative delivery, which enhances satisfaction compared to traditional, rigid methods.

While following processes (A) and using agile techniques (B) are means to an end, they do not directly guarantee benefits. Focusing solely on tasks (D) risks losing sight of value delivery.

User satisfaction is a central measure of agile success and reflects the effective application of agile principles.

Agile Foundation guidance explains that the purpose of the agile enablement workshop is to identify, assess, and plan for risks associated with Agile adoption, making option C the correct answer. This workshop is a structured activity designed to help organizations and project teams understand how well Agile ways of working fit their specific context and what challenges may arise when adopting Agile approaches.

The agile enablement workshop focuses on readiness rather than delivery execution. It examines factors such as organizational culture, governance expectations, stakeholder engagement, team capability, leadership support, and external constraints. By discussing these areas openly, participants can identify potential barriers to Agile adoption, assess their impact, and agree on actions to reduce or manage those risks. This proactive approach supports informed decision-making and avoids unrealistic expectations about Agile.

Option A, risks associated with project delivery, relates more to traditional project risk management practices. Option B, team delivery risks, focuses narrowly on team-level execution issues rather than adoption. Option D, enterprise agility risks, applies at a broader organizational transformation level and goes beyond the typical scope of an agile enablement workshop, which is usually project- or initiative-focused.

Agile Foundation documents emphasize that Agile adoption is not risk-free and should be approached thoughtfully. The agile enablement workshop helps ensure that Agile is tailored appropriately rather than applied mechanically. It supports alignment between Agile teams and governance structures, clarifies where flexibility is possible, and highlights where controls are required. By identifying and planning for adoption risks early, organizations increase the likelihood of successful Agile implementation while preserving the core values of adaptability, collaboration, and value-driven delivery.

Trading/swapping is a technique used within the issues practice to manage and resolve conflicts or competing priorities by negotiating trade-offs. For example, scope items, resources, or deadlines may be traded or swapped between stakeholders to reach agreements that keep the project on track.

This collaborative negotiation supports flexible, pragmatic issue resolution, aligning with agile values of collaboration and customer focus. It enables project teams to balance competing demands while maintaining progress and business justification.

Objectives and key results (B) are goal-setting tools, refactoring (C) is a technical practice for code improvement, and delegation poker (D) is about decision-making authority — none specifically target issue resolution.

Trading/swapping aligns with PRINCE2’s controlled management of issues and agile’s collaborative problem-solving approach.

The Team Planning Workshop is primarily held to update the product backlog. This collaborative session allows the delivery team to break down, refine, and reprioritize user stories or tasks to prepare for the upcoming iteration or sprint. The team reviews the product backlog items, clarifies acceptance criteria, estimates effort, and commits to the planned work.

Updating the product backlog at this level ensures that detailed planning aligns with the overall project vision and release goals. It empowers the team to self-organize and manage their workload, supporting agile principles of autonomy and collaboration.

While the project dashboard (A) provides status reporting, the release map (C) focuses on higher-level release planning, and OKRs (D) relate to strategic objectives, these are not the central focus of the team planning workshop.

PRINCE2 Agile promotes team planning workshops as essential forums for translating business priorities into actionable, manageable work for delivery teams.

Agile Foundation guidance, aligned with PRINCE2 Agile, explains that the Definition of Ready (DoR) and Definition of Done (DoD) should be agreed as early as possible to establish clear expectations around quality, readiness, and completion. The workshop to agree both DoR and DoD is conducted during the Initiating a Project process, making option A the correct answer.

The Initiating a Project process is where the foundations for successful delivery are set. Its purpose is to ensure that there is a shared understanding of how the project will be delivered, governed, and controlled before significant work begins. Agreeing the DoR and DoD at this stage provides clarity on what “ready to start” and “done” actually mean for the project. This helps align stakeholders, delivery teams, and governance roles on quality expectations and acceptance standards.

Option B, Directing a Project, focuses on senior-level decision-making, authorization, and overall control rather than detailed delivery agreements. Option C, Controlling a Stage, deals with monitoring progress and handling issues during execution, not defining core quality agreements. Option D, Managing Product Delivery, concentrates on coordinating work between the team and project management but assumes that definitions such as DoR and DoD are already established.

Agile Foundation documents emphasize that DoR and DoD support transparency, consistency, and trust. The DoR ensures that work entering a delivery cycle is sufficiently understood and prepared, reducing waste and rework. The DoD ensures that completed work meets agreed quality criteria and is potentially releasable. Establishing these definitions during Initiating a Project supports Agile principles of built-in quality and shared understanding, while also satisfying governance needs. By agreeing them early, teams can work autonomously within clear boundaries, improving flow, predictability, and value delivery throughout the project.

Agile Foundation guidance identifies the Agilometer assessment as a key tool used to assess risks associated with Agile adoption, making option C the correct answer. The Agilometer is specifically designed to evaluate how suitable Agile approaches are for a particular project, team, or organizational context before or during adoption. It helps organizations understand the level of risk involved in applying Agile and highlights areas that may need additional support, tailoring, or controls.

The Agilometer works by assessing several dimensions related to Agile readiness, such as stakeholder engagement, organizational culture, team capability, leadership support, and delivery environment. By scoring these factors, it provides a structured and transparent view of potential risks and constraints. This allows decision-makers to identify where Agile is likely to succeed easily and where challenges may arise, enabling proactive risk management rather than reactive problem-solving.

Option A, an enterprise agility assessment, focuses on overall organizational maturity and long-term transformation rather than project-level or adoption-specific risks. Option B, a project dashboard, is used for tracking progress, metrics, and status, not for assessing suitability or adoption risk. Option D, a cumulative risk burn-down chart, may be used to visualize risk reduction over time, but it does not assess whether Agile adoption itself is appropriate or risky in a given context.

Agile Foundation documents emphasize that Agile is not a one-size-fits-all solution. The Agilometer supports informed decision-making by encouraging thoughtful consideration of constraints, governance needs, and cultural readiness. By identifying adoption risks early, organizations can tailor Agile practices, apply hybrid approaches where necessary, and set realistic expectations. This structured assessment helps protect value delivery while maintaining the flexibility and responsiveness that Agile aims to provide.

Artificial Intelligence (AI) in PRINCE2 Agile is recognized as a tool that can assist in reducing uncertainty and ambiguity by providing data-driven insights, predictive analytics, and automation of routine tasks. This support helps teams better understand changing environments and respond faster, thereby addressing complexity associated with change initiatives.

While AI can add complexity if misused, PRINCE2 Agile focuses on its beneficial role in supporting decision-making and reducing unknowns rather than complicating governance or communication.

A well-recognized challenge when merging traditional project management with Agile approaches is the use of different terminology, making option B the correct answer. Agile Foundation materials highlight that traditional project management and Agile have evolved from different perspectives, each with its own language, concepts, and assumptions. When these approaches are combined within the same organization or project, misunderstandings often arise due to terminology differences rather than fundamental conflicts in intent.

Traditional project management commonly uses terms such as scope, milestones, deliverables, baselines, and change control, while Agile uses concepts like backlog, iterations, increments, velocity, and value delivery. Even when the underlying goals are aligned, different terminology can create confusion among stakeholders, project managers, Agile teams, and senior leadership. This confusion may lead to misaligned expectations, incorrect reporting, or resistance to Agile practices, as people may interpret the same words differently or assume conflicting meanings.

Option A, lack of clear processes, is generally not a common issue because both project management and Agile provide structured approaches, albeit in different forms. Option C, lack of guidance at the project level, is also not accurate, as Agile Foundation guidance increasingly addresses how Agile can operate at team, project, and organizational levels. Option D, the use of a flexible framework, is actually a benefit of Agile rather than a challenge.

Agile Foundation documents emphasize that overcoming terminology differences requires education, shared understanding, and alignment rather than choosing one approach over the other. By establishing a common language, clarifying roles and expectations, and focusing on value delivery rather than labels, organizations can successfully integrate Agile ways of working with project management governance. Addressing terminology differences early helps reduce friction, improves collaboration, and enables a more effective hybrid or Agile-informed project environment.

The Recommend step in issue management involves analyzing the issue and evaluating possible options to resolve it. At this stage, the project team or responsible individuals identify potential solutions, weigh their pros and cons, and recommend the best course of action to decision-makers.

Capture is the initial identification and recording of the issue, Decide involves making the final decision on the recommended solution, and Implement is the execution of the chosen resolution. Evaluating options thoroughly during the Recommend phase helps ensure informed decision-making and effective issue resolution.

This structured approach aligns with PRINCE2’s focus on proactive issue management, maintaining control and reducing risk impacts.

Delegation poker is a collaborative game used to define and clarify decision-making authority within teams. It helps teams agree on who has the power to make decisions for specific areas, from the team level to senior management. Using cards representing different levels of delegation, team members discuss and align expectations, ensuring clarity and reducing conflicts.

This technique fosters transparency, shared ownership, and empowerment, which are critical for agile teams operating under PRINCE2 governance. It also helps balance autonomy and control, supporting the principle of manage by exception.

Other options: a team skills matrix documents competencies, personas represent user archetypes for design, and magic estimation is a sizing technique — none focus on decision authority.

Delegation poker aligns well with PRINCE2 Agile’s emphasis on defined roles and empowered teams.