PRINCE2-Agile-Foundation Questions and Answers

The Team Retrospective Workshop is explicitly designed to facilitate team growth and continuous improvement in working practices. It is a fundamental agile practice where the team reflects on the recently completed work or sprint to identify what went well, what didn’t, and what could be improved. The goal is to foster an environment of trust and openness, enabling teams to discuss challenges and successes honestly.

Retrospectives promote inspect and adapt principles by encouraging teams to continuously evaluate their processes, collaboration, and tools. They help uncover systemic issues, process bottlenecks, or interpersonal challenges that may be impeding productivity or quality. Teams use this feedback to implement actionable improvements, which can range from adjusting communication methods to refining definitions of done or ready.

This workshop supports a key agile mindset—continuous learning and improvement—which directly contributes to team maturity, performance, and morale. Importantly, retrospectives are not about assigning blame but rather about fostering a growth mindset that accepts change as an opportunity to evolve.

While Project Kickoff Workshops (A) initiate project alignment and Progress Review Workshops (C) monitor project status, they do not primarily focus on team process improvements. The Team Planning Workshop (D) is concerned with planning upcoming work, not retrospection.

In PRINCE2 Agile, retrospectives are a critical tool to blend traditional project management with agile principles by promoting regular reflection and incremental enhancements.

The Managing Product Delivery process includes agreeing on and controlling the requirements for the delivery of specialist products. This process ensures that team managers understand the scope and quality expectations before work begins and that delivery aligns with the project plan.

Initiating a project and starting up a project establish overall direction but do not handle detailed delivery requirements. Managing a stage boundary reviews progress and plans the next stage.

This process maintains clarity and accountability for delivery within PRINCE2’s framework, facilitating effective control over specialist products.

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.

Agile Foundation guidance clearly states that the transition from merely “doing Agile” to truly “being Agile” is driven by adopting an Agile mindset, making option C the correct answer. An Agile mindset represents a set of beliefs, attitudes, and ways of thinking that prioritize flexibility, learning, collaboration, and continuous improvement over rigid plans and fixed assumptions. Without this mindset, Agile practices often become mechanical routines that fail to deliver their intended benefits.

“Doing Agile” typically involves implementing visible practices such as daily stand-ups, iterations, backlogs, or boards. While these practices are useful, Agile Foundation documents emphasize that they only create lasting value when supported by the right mindset. “Being Agile” means embracing uncertainty, welcoming change, learning from feedback, and focusing on delivering value rather than following predefined plans. The Agile mindset encourages experimentation, reflection, and adaptation at both team and organizational levels.

Option A, the Agile Onion, is a conceptual model that explains the layers of Agile but does not itself transform behavior. Option B, psychological safety, is an important enabler that allows people to speak up, learn, and collaborate, but it is not the overarching driver of Agile transformation. Option D, Agile sustainability, focuses on maintaining Agile ways of working over time rather than initiating the shift from doing to being Agile.

Agile Foundation documents highlight that an Agile mindset fosters a culture where learning is continuous and failure is treated as an opportunity to improve. Leaders support this mindset by empowering teams, encouraging autonomy, and focusing on outcomes instead of outputs. When an organization adopts an Agile mindset, practices become adaptable tools rather than rigid rules. This cultural shift is what truly transforms an organization, enabling it to respond effectively to change, innovate continuously, and remain focused on delivering value.

Agile workshops are collaborative sessions used throughout the project to address various aspects such as problem-solving, release planning, team alignment, and continuous improvement. Workshops encourage open communication, collective decision-making, and foster a shared understanding of goals and challenges.

Unlike a delegation matrix, which defines roles and authorities, or the project log, which records issues and risks, workshops are interactive events that enable timely resolution of challenges. The Agilometer is a diagnostic tool assessing agility maturity but not a problem-solving forum.

Agile workshops embody the agile principle of collaboration and adaptability, enabling teams to respond quickly to issues and refine plans collectively.

One of the significant challenges when merging traditional project management approaches like PRINCE2 with agile delivery methods is the lack of guidance on doing agile. While PRINCE2 provides a structured framework focusing on governance, control, and business justification, agile introduces flexible, iterative, and people-centered approaches. The integration of these requires clear guidance on how to implement agile practices effectively within the PRINCE2 framework.

PRINCE2 Agile acknowledges that while it offers a comprehensive method to combine governance and agility, many organizations and practitioners struggle with practical implementation, especially in how to “do agile” properly. This includes understanding how to adopt agile roles, ceremonies, and artifacts without losing control, as well as aligning agile delivery with PRINCE2’s management layers.

The challenge is compounded by the fact that agile methodologies emphasize adaptive planning and team autonomy, whereas traditional project management often focuses on upfront planning and command-and-control structures. PRINCE2 Agile aims to bridge this gap by providing detailed guidance, but a lack of practical ‘how-to’ agile advice remains a common issue.

Other options like terminology differences (A), unclear processes (B), and guidance at delivery level (C) are lesser challenges because PRINCE2 Agile provides a common vocabulary and defined processes that include delivery considerations.

A key criterion for the Definition of Ready is that acceptance criteria are measurable. This ensures that work items are clearly understood, well-defined, and have objective criteria to confirm when they are complete. Measurable acceptance criteria reduce ambiguity and support efficient development and quality assurance.

Other options describe completion or handover stages, which are more relevant to the Definition of Done, not Ready.

Within Agile Foundation guidance and PRINCE2 Agile alignment, the Definition of Done (DoD) plays a critical role in supporting an iterative approach to delivery, making option C the correct answer. PRINCE2 Agile combines the governance strengths of PRINCE2 with the flexibility of Agile delivery, and iteration is central to how value is delivered incrementally. The DoD provides a shared and consistent understanding of what it means for work to be complete at the end of each iteration.

The iterative approach in PRINCE2 Agile relies on delivering small, usable increments frequently. The Definition of Done ensures that every increment meets agreed quality standards before it is considered complete. This supports transparency, predictability, and trust, which are essential for iterative delivery. Without a clear DoD, teams risk producing partially finished work that cannot be reviewed, tested, or released, undermining the benefits of iteration.

Option A is incorrect because Agile and PRINCE2 Agile emphasize continuous feedback as a core mechanism for learning and adaptation. Option B, offering predictive insights, is not a defining element of PRINCE2 Agile’s iterative approach; Agile focuses more on empirical feedback than prediction. Option D is also incorrect because frequent testing is encouraged, not reduced, in iterative Agile delivery.

Agile Foundation documents emphasize that the DoD acts as a quality gate that supports incremental progress while maintaining control. It aligns delivery teams and stakeholders on expectations and ensures that each iteration produces a potentially usable output. In PRINCE2 Agile, this alignment allows teams to work autonomously within defined tolerances while still meeting governance and assurance requirements. By clearly defining what “done” means, the DoD strengthens the iterative cycle of build, review, learn, and adapt, which is fundamental to Agile and PRINCE2 Agile working together.

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 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.

‘Being agile’ refers to embracing the mindset and principles of agility, not just following agile practices mechanically. Option D illustrates ‘being agile’ because the customer has embraced the iterative approach and focuses on requirements that add real value, which reflects true agile values such as customer collaboration, responding to change, and delivering value early and continuously.

Options A, B, and C describe activities related to agile practices but don’t necessarily reflect the deeper agile mindset or cultural shift fundamental to ‘being agile’.

Agile Foundation guidance often explains Agile concepts using the “Agile Onion” model, which shows how different layers of Agile build upon one another. Within this model, principles provide the core guidelines that help teams understand the purpose behind Agile practices, making option D the correct answer. Principles act as a bridge between high-level values and practical methods, explaining why certain ways of working are encouraged.

The Agile Onion typically places mindset at the center, followed by values, then principles, and finally practices, techniques, and processes on the outer layers. While practices describe what teams do and processes describe how work flows, principles explain the intent that guides those actions. They help teams make informed decisions when situations change or when standard practices do not fit the context. By understanding principles, teams can adapt their practices while still remaining aligned with Agile thinking.

Option A, processes, focus on structured sequences of activities and are concerned with execution rather than purpose. Option B, mindset, represents underlying beliefs and attitudes, which shape behavior but do not explicitly provide guidance on how or why specific practices are used. Option C, values, define what is important, such as collaboration or customer focus, but they do not give enough direction on how to translate those values into action.

Agile Foundation documents emphasize that principles are essential for sustainable Agile adoption. They enable teams to move beyond mechanical “doing Agile” and toward thoughtful “being Agile.” When teams understand the principles behind practices, they are better equipped to tailor their approach, respond to change, and apply Agile effectively in different environments. Principles ensure consistency of intent while allowing flexibility in execution, which is fundamental to Agile success.

When transitioning from project delivery into business as usual (BAU), establishing regular feedback loops is crucial to ensure continual improvement. Feedback loops enable ongoing monitoring, learning, and adaptation of both products and processes post-transition. They provide mechanisms for capturing user experiences, operational issues, and evolving requirements that inform future iterations and enhancements.

Feedback loops can take many forms, such as user surveys, retrospectives, operational reviews, or service desk reports. Their regularity and structure ensure that BAU teams remain aligned with customer needs and organizational goals while adapting to changes effectively. This approach fosters a culture of continuous learning and agility even after the formal project has closed.

Providing access to Kanban or team boards (A) supports transparency and workflow management but is more tactical and internal to teams rather than a strategic approach to continuous improvement across BAU. Agreeing on SLAs (C) and KPIs (D) define performance and service targets but do not inherently drive feedback or improvement cycles without mechanisms for learning and response.

PRINCE2 Agile highlights the importance of feedback loops as part of the ‘progress’ and ‘quality’ practices extended into BAU to sustain value delivery.

The product owner is responsible for preparing and maintaining the product backlog, ensuring it accurately reflects user requirements, priorities, and acceptance criteria. This role acts as the voice of the customer, maximizing product value by managing backlog items, ordering them to reflect business priorities, and clarifying requirements for development teams.

Monitoring stage progress (A) and managing project-level risks (B) are typically roles of the project manager or risk owner within PRINCE2 governance. The project backlog (C) contains higher-level requirements for the entire project and is not the product owner's direct responsibility.

The product owner bridges business and delivery, ensuring the team works on the most valuable features while maintaining clarity and quality of backlog items.

Culture refers to the collective attitudes, values, beliefs, and goals shared by a group or organization. It shapes how people behave, make decisions, and interact. In PRINCE2 Agile, understanding and adapting organizational culture is critical for successful agile adoption and delivery.

Leadership (B) influences culture but is distinct, co-creation (C) is a collaborative approach, and management (D) relates to planning and control activities.

A positive, agile-friendly culture fosters openness, trust, and continuous improvement.

The project closure workshop is held to formally close the project, during which project documentation is updated to reflect the final state of the project, lessons learned are captured, and approvals are obtained. This ensures that all activities are completed, the project has delivered its intended products, and knowledge is retained for future projects or organizational learning.

Aligning teams (A) and refining release maps (D) are activities conducted earlier in the lifecycle, while benefits management (B) is usually defined during initiation and planning stages.

User inputs are initially gathered as user stories in the product backlog in PRINCE2 Agile. User stories represent small, customer-focused requirements that capture the "who," "what," and "why" of a feature. These stories form the foundation of requirements and quality criteria for the product and ensure that development is driven by user needs and value delivery.

The Definition of Done is developed later as part of the quality management approach to specify when work is complete. Epic user stories are larger features that can be broken down into smaller user stories. The quality register tracks quality-related activities but is not the first step for gathering user inputs.

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.

Agile Foundation guidance describes co-creation as a collaborative approach where value is created together by people who share common attitudes, values, and goals. This makes option C the correct answer. Co-creation goes beyond simply assigning work or motivating individuals to meet predefined objectives. Instead, it emphasizes collective ownership, shared understanding, and active participation by all relevant stakeholders in shaping outcomes.

In Agile environments, co-creation is rooted in the belief that the best solutions emerge when diverse perspectives work together in an open and trusting environment. Teams, customers, users, and stakeholders collaborate continuously to explore needs, generate ideas, and refine solutions. This shared mindset ensures that everyone involved is aligned on purpose and value, rather than working in isolation or following instructions without context.

Option A focuses on motivation to meet objectives, which reflects performance management rather than co-creation. While motivation is important, it does not necessarily involve shared ownership or joint value creation. Option B, agreeing ways of working, relates to establishing working agreements or team norms, which support collaboration but do not define co-creation itself. Option D, instructing the execution of tasks, represents a command-and-control approach that is contrary to Agile principles and does not encourage shared responsibility or creativity.

Agile Foundation documents emphasize that co-creation strengthens engagement, trust, and innovation. When people share attitudes, values, and goals, they are more likely to challenge assumptions constructively, learn from each other, and adapt solutions based on feedback. This approach supports Agile principles such as collaboration, customer focus, and continuous improvement. Co-creation ensures that value is not simply delivered to stakeholders but created with them, leading to better outcomes, higher satisfaction, and more sustainable Agile ways of working.

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.

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.