PRINCE2-Agile-Practitioner Sample Questions & Answers

This is the most comprehensive and appropriate PRINCE2 Agile approach. It correctly identifies Scope and Benefits as flexible given the fixed Time and Cost. It directly addresses the 'easy to release' risk by creating a work package to improve the deployment process early on. It tackles the 'customer doesn't need everything' risk by instituting a formal, collaborative prioritization process (MoSCoW) through workshops. This strategy proactively manages the identified risks within the project's constraints.

This correctly describes the flow of information in PRINCE2 Agile. The delivery team's progress is captured at a detailed, frequent level (e.g., in Checkpoint Reports or via information radiators). The project manager then synthesizes this information, focusing on progress against stage tolerances and the business case, into a less frequent, higher-level Highlight Report for the project board. This keeps the board informed at the right level of detail.

PRINCE2 Agile guidance clearly suggests that the Team Manager role is the most natural fit for a Scrum Master. The Team Manager is responsible for managing the delivery team and ensuring products are created to the required quality, which aligns well with the Scrum Master's responsibilities of facilitating the Scrum process and removing impediments for the delivery team.

A spike is a specific type of user story or task that is used to gain knowledge or answer a question, thereby reducing technical or functional uncertainty. It is timeboxed and intended to provide just enough information to make a decision. This is the perfect agile technique for quickly investigating the two technology options to determine feasibility.

Kanban is a flow-based system where work is 'pulled' by the team as they have capacity. Therefore, a Work Package for a Kanban team should be framed as a queue of prioritized items that the team can draw from. In contrast, a Work Package for a Scrum team is typically a set of objectives or features to be achieved within a specific timebox (the sprint). The structure reflects the fundamental difference between flow-based and timeboxed agile approaches.

Retrospectives are a core agile practice for reflecting on the process and identifying improvements, directly supporting learning from experience at the delivery level.

The Lessons Log is the formal PRINCE2 mechanism for capturing and communicating lessons, ensuring they are considered throughout the project and for future projects.

Daily stand-ups facilitate rapid, daily learning cycles by highlighting what is and isn't working, allowing for immediate adjustments.

The 'Starting Up a Project' process is where the initial assessment of the project is made. The Cynefin framework helps to categorize the problem space (Simple, Complicated, Complex, Chaotic). Using it here helps determine the level of uncertainty and complexity involved, which in turn informs how much agility is required and how the overall project should be approached. This is a crucial early step before detailed planning in the 'Initiating a Project' process.

The guidance point 'PRINCE2 governance can enable agile' is specifically about how the framework's controls (like stages, tolerances, and exception reporting) provide the oversight and decision-making authority that a project board needs, while still allowing the delivery team the freedom to work in an agile way. Emphasizing this helps reassure the board that they are not losing control, but rather exercising it in a more adaptive manner.

The 'Manage by Exception' principle is fundamental to PRINCE2. The project manager has identified a forecast breach of stage tolerances. Their authority is limited by these tolerances, so they must escalate the issue to the project board. The formal mechanism for this is the Exception Report. This report should present the situation, analyze the impact, and propose options, which would be the appropriate forum to discuss the new high-priority requirement and its effect on the project's scope, time, and cost.

False. Frequent releases are a delivery mechanism. The 'Closing a Project' process is a formal management activity to ensure the project is properly shut down. This includes final acceptance of the project product, confirming that benefits have been or will be realized, assessing project performance, and formally disbanding the project team. Even if the final product was delivered in the last release, these formal closure activities are still required.