AgilePM-Foundation Questions and Answers

The Agile Manifesto explicitly values “individuals and interactions over processes and tools.” AgilePM fully aligns with this principle. While processes, tools, documentation, and contracts are important and often necessary (especially for governance, compliance, and clarity), they should not take precedence over effective collaboration, empowered teams, and rapid feedback. AgilePM’s practices—facilitated workshops, daily coordination, frequent reviews, and active business involvement—are designed to maximize human interaction to reduce waste, accelerate understanding, and improve quality. Even in regulated or contractual contexts, AgilePM recommends shaping processes and agreements to enable collaboration (e.g., clear roles, decision latency reduction, acceptance criteria, and incremental validation) rather than letting procedures dominate. Therefore, no listed circumstance justifies prioritizing processes and tools over individuals and interactions. The right choice is D. None of the above.

Agile Project Management places a premium on collaboration—the act of different roles (business, product, and technical) working together toward a shared goal. While communication is the exchange of information, collaboration goes further: it is joint problem-solving and decision-making that aligns perspectives to deliver value. AgilePM/DSDM principles explicitly promote active business involvement and empowered teams, creating an environment where collaboration is the default for refining requirements, planning increments, resolving trade-offs, and assuring quality. Ceremonies such as backlog refinement, Sprint Planning, daily coordination, and reviews exist to reinforce collaborative behavior, shorten feedback loops, and surface constraints early. Scrum itself (option C) is a framework that enables collaboration, but the definition given—“working together towards a shared goal”—is the definition of collaboration, not the framework or governance mechanisms. Governance (option D) concerns oversight and control structures rather than the cooperative behaviors that produce outcomes. Consequently, the statement most accurately and directly defines Collaboration.

In a DSDM project, contingency is typically managed by varying the features to be delivered6. This approach aligns with the DSDM principle of delivering the most critical work first and using the MoSCoW prioritization to adjust the scope of delivery as needed.

Statement 1: Correct. The change curve describes typical emotional responses to change, including denial, resistance, exploration, and commitment.

Statement 2: Incorrect. The change curve applies to both positive and negative changes, as it reflects the adjustment process regardless of the perceived nature of the change.

Key AgilePM Concepts Referenced:

Emotional Responses to Change: AgilePM Handbook, Chapter 6, Section 6.3.

 The Delivery Plan defined by DSDM has a planning horizon that includes the end of the project7. This plan looks towards the future, often months or years ahead, to guide the incremental delivery of the project’s outcomes.

Timeboxing is the technique that allows for testing the achievability of objectives. This approach involves setting a fixed period (the Timebox) during which specific tasks or objectives must be completed. By focusing on what can be achieved within the set time frame, Timeboxing helps teams test and validate whether their objectives are realistic and attainable. This iterative approach ensures continuous assessment and adaptation, promoting efficient project management.

Autonomy, Mastery, and Purpose: As outlined by Daniel Pink, these three factors drive motivation in knowledge work, which relies on creativity and engagement. Agile practices support autonomy through self-organizing teams, mastery through continuous learning, and purpose through shared goals.

Other Options: These reflect traditional or outdated models of motivation and do not align with Pink’s framework.

Key AgilePM Concepts Referenced:

Motivating Teams: AgilePM Handbook, Chapter 5, Section 5.7.

AgilePM sits at the project level, framing delivery within business justification, governance, stakeholder engagement, risk, funding, and release management. This is a wider context than the mechanics of product development, which concentrates on evolving the product incrementally (requirements, design, build, test) using frameworks like Scrum. AgilePM aligns product delivery with organizational goals via a Business Case, clear roles, stage/phase control, and timeboxing, while enabling adaptive scope through prioritization. Product development is a vital subset, but project management additionally addresses cross-team dependencies, external stakeholders (e.g., operations, compliance), transition to live service, and benefits enablement. Options B, C, and D either overstate comparative complexity, misstate product development’s focus, or confuse product delivery with governance structures. The accurate statement is that project management operates in a broader organizational and governance context than product development—exactly what AgilePM was designed to harmonize with agile delivery methods.

Statement 1: Incorrect. Communication plans should be tailored to the specific context of each change initiative, as a one-size-fits-all approach does not work.

Statement 2: Correct. The scale and complexity of change will dictate the content and level of detail in the communication plan.

Key AgilePM Concepts Referenced:

Tailored Communication Plans: AgilePM Handbook, Chapter 4, Section 4.3.

The DSDM product that describes how the benefits have actually accrued following a period in live operation is the Benefits Assessment3. This product is used to assess the actual benefits realized after the solution has been in use3.

Comprehensive and Detailed Explanation (paraphrased from AgilePM/Agile standards; exact long extracts cannot be provided):

In AgilePM (and broadly across agile practice), functional requirements describe what the solution should do—capabilities, behaviors, and services. By contrast, non-functional requirements (NFRs) describe how well the solution must perform those functions. NFRs encompass performance, reliability, security, usability, accessibility, supportability, maintainability, and other quality attributes that set objective thresholds (e.g., response times, availability targets, encryption standards). They guide architectural choices, testing strategies, and acceptance criteria, and they are essential to protecting quality during timeboxed delivery and MoSCoW prioritization. Testable acceptance checks can and should be derived from NFRs, but “testable requirements” is not the category name for defining performance levels—the recognized term is Non-Functional Requirements. Therefore, the correct option is B.

Agile delivery expects each increment to be usable, meet the agreed quality bar (Definition of Done), and move the product toward its goal. AgilePM’s incremental, timeboxed approach stresses that every slice should be demonstrably valuable or verifiable, with acceptance criteria satisfied and quality never compromised. However, increments in an evolving solution are typically additive and cumulative; they build upon prior work to extend capability. Requiring that an increment be independent of all others is unnecessary and often impractical for integrated solutions. What matters is that it is coherent, tested, and acceptable to stakeholders within the agreed standards. Thus, options A, C, and D describe standard expectations for an increment in AgilePM/Scrum-aligned practice, whereas B does not. Therefore, B is the correct “NOT” choice.

Solution increments are created during the Evolutionary Development phase. This phase is where the solution is developed iteratively, building on the firm foundations laid out in the previous phases1. It involves creating increments of the product through time-boxed iterations, ensuring that the solution evolves in line with the project’s objectives and business needs.

Communicating the Danger of Inaction: Highlighting risks of not changing amplifies dissatisfaction with the status quo, creating urgency and driving motivation for change.

Other Options:

A: Performance targets align with accountability, not dissatisfaction.

C: Clarifying steps supports action but doesn’t address dissatisfaction.

D: Benefits focus on the positive outcome, not dissatisfaction.

Key AgilePM Concepts Referenced:

Change Formula Framework: AgilePM Handbook, Chapter 6, Section 6.5.

Comprehensive and Detailed Explanation (paraphrased from Agile Project Management guidance):

Agile leadership distributes authority and nurtures autonomy so that decisions can be made closest to the work. The principle that most clearly embodies empowerment, shared ownership, and accountability at every level is “Leadership lives everywhere in the organization.” This principle encourages leaders to create the conditions for others to lead—clarifying intent, aligning on outcomes, and then trusting teams to own decisions within clear boundaries. It contrasts with command-and-control models by fostering psychological safety, inviting initiative, and rewarding collaborative problem-solving. While feedback (B), meaning and purpose (C), and healthy engagement with emotion (D) are all important, they are supporting principles. The scenario described—empowering others and spreading accountability—maps directly to leadership as a shared organizational capability, not a title. This accelerates learning, reduces decision latency, and enables adaptive responses to change—hallmarks of agile organizations.

Within the Solution Development team, it is not required for all members to be multi-skilled experts1. While a diverse set of skills is beneficial, DSDM emphasizes collaboration and the effective use of individual strengths rather than expecting every team member to be an expert in all areas1.

The DSMD (Dynamic Systems Development Method) principle of “Build incrementally from firm foundations” emphasizes the importance of having a solid understanding of the project’s foundation before proceeding with incremental development. This principle ensures that each increment is built upon a stable base, which supports the overall project integrity and success.

Comprehensive and Detailed Explanation (verified, paraphrased from AgilePM principles):

AgilePM promotes incremental and iterative delivery, aiming to deploy usable increments early and often. Regular deployment and demonstration validate fitness for purpose, expose risks sooner, and provide empirical feedback for planning. Early release of increments also tests assumptions about value with real users and stakeholders, informing prioritization (e.g., MoSCoW) and shaping subsequent increments. This approach supports continuous learning, sharper benefits focus, and stronger financial governance, because funding and scope decisions can be based on evidence from working solution slices rather than predictions. Hence, both statements accurately reflect agile project delivery.

Certainty in Neuroscience: The brain seeks predictability and stability, which is supported by delivering change in small, incremental stages. This approach aligns with Agile's iterative and incremental delivery, providing clarity and reducing stress for individuals undergoing change.

Other Options:

B: Delegated decision-making relates to empowerment but does not directly address certainty.

C: Group social events foster connection, not certainty.

D: Public praise boosts morale but doesn’t satisfy the need for predictability.

Key AgilePM Concepts Referenced:

Iterative and Incremental Delivery: AgilePM Handbook, Chapter 3, Section 3.6.

Statement 1: Correct. Leading by example is crucial for inspiring trust and alignment with the change vision. Symbolic actions by leaders play a significant role in fostering engagement.

Statement 2: Incorrect. Change influence is not limited to leaders; team members and change agents can also drive and inspire change.

Key AgilePM Concepts Referenced:

Role of Leadership in Change: AgilePM Handbook, Chapter 6, Section 6.2.

Comprehensive and Detailed Explanation (paraphrased from AgilePM governance guidance):

AgilePM’s financial governance relies on artifacts that demonstrate continuing business justification, predictable control, and informed decision-making. Core project artifacts include the Feasibility Assessment (early viability and value assessment), the Foundations Summary (establishes the Business Case, scope, approach, plans, and controls), and the Project Review Report (evidence-based assessments of progress, benefits, and risks). These directly support budget stewardship, investment decisions, and release planning. A Sprint Review Record is a Scrum team-level event output focused on inspecting increments and adapting the Product Backlog; it is not a defined AgilePM project artifact nor specifically a financial governance instrument. While insights from reviews inform governance, the formal artifacts tied to AgilePM’s project-level financial control are exemplified by options A, C, and D—hence B is the correct “NOT” choice.

In DSDM, the Minimum Usable Subset refers to the “Must Have” requirements as defined by the MoSCoW prioritization1. This subset ensures that the project delivers the core functionalities that are critical for the system to be considered useful and viable2.

Statement 1: Incorrect. While accountability is important, it should be addressed constructively, not by drawing attention to failures in a punitive way.

Statement 2: Incorrect. Constructive conflict is essential for innovation and problem-solving. Avoiding conflict entirely can lead to unresolved issues and reduced performance.

Key AgilePM Concepts Referenced:

Team Dynamics and Conflict Management: AgilePM Handbook, Chapter 5, Section 5.5.

Financial: A measurable increase in sales reflects improved financial performance, making it a financial metric. Financial views in a change delivery scorecard often include profitability, revenue growth, and ROI—all of which are influenced by sales increases.

Customer, Internal, Learning & Growth: These are equally important views but do not directly relate to sales performance. For instance:

Customer View: Focuses on customer satisfaction and loyalty.

Internal View: Addresses process efficiency.

Learning & Growth View: Pertains to employee development and organizational innovation.

Key AgilePM Concepts Referenced:

Scorecard and Value Metrics: AgilePM Handbook, Section 2.5.3.

The AgilePM lifecycle typically includes Pre-Project, Feasibility, Foundations, Evolutionary Development/Realization, Deployment, and Post-Project (benefits). Feasibility is designed as a lightweight, optional phase to confirm there is a sensible case to proceed before deeper investment. In some contexts—when viability is already established, or scope and constraints are straightforward—Feasibility may be skipped or greatly abbreviated, moving directly to Foundations, where the approach, governance, and baselines are established. By contrast, Foundations is expected for alignment and control, and Realization (timeboxed delivery) is where the solution is built; these are not optional if you are proceeding with delivery. Thus, Feasibility is the optional phase.

AgilePM emphasizes lightweight but effective planning that maintains control without bureaucracy. Core planning concepts include timeboxing (fixed-duration delivery windows), MoSCoW prioritization (flexing scope to protect time/cost/quality), incremental and iterative delivery (frequent demonstrations and review), and rolling-wave planning (planning at multiple horizons). Together these techniques ensure transparency, predictable cadence, and early value while avoiding heavyweight documentation or rigid stage gates. Plans are living forecasts refined through continuous feedback and empirical evidence from delivered increments. Governance focuses on outcomes and fitness for purpose rather than exhaustive upfront detail. This is why the guidance often summarizes that AgilePM planning “keeps projects on track,” enabling teams to respond to change, surface risks early, and align stakeholders around real progress. Options A, C, and D capture fragments of agile practice, but they understate the project-level intent. The correct completion is “projects on track.”

Actively Involve Line Managers: Change management frameworks highlight the importance of involving line managers to support individuals through the emotional phases of the change curve. Line managers can offer guidance, listen to concerns, and provide the reassurance needed to navigate uncertainty.

Why the Other Options Are Incorrect:

B: Negative emotions are a normal part of the change curve and should not automatically be seen as mismanagement.

C: Discouraging discussion can create further resistance and disengagement.

D: Assuming individuals will adapt over time neglects the need for proactive engagement and support.

Key AgilePM Concepts Referenced:

Navigating the Change Curve: AgilePM Handbook, Chapter 6, Section 6.3

Comprehensive and Detailed 150–300 words Explanation (paraphrased from AgilePM/DSDM guidance):

In AgilePM, the Business Sponsor is the project’s ultimate decision-maker and the role accountable for ensuring continued business justification. This includes owning the investment decision, securing and sustaining funding, and maintaining senior-level commitment to the business opportunity. A lack of commitment represents a threat to the viability of the Business Case; managing and mitigating that risk sits squarely with the Sponsor. The Sponsor establishes clear objectives, champions the initiative across the organization, removes high-level impediments, and ensures that governance supports timely decisions. While the Business Visionary articulates and safeguards the solution vision and value outcomes, that role does not control organizational commitment or funding at the enterprise level. Similarly, Business Advisors provide specialist input but do not own commitment or investment risk. Therefore, where commitment to the business opportunity is wavering or unclear, the Business Sponsor is responsible for intervening—reconfirming the Business Case, rallying stakeholder support, and aligning investment, scope and timescales—so the project remains justified and deliverable.

AgilePM distinguishes between increments in terms of what is actually delivered to stakeholders. The emphasis is on a Solution—the integrated outcome that delivers business value—not merely isolated technical outputs. As delivery progresses, teams create Solution Increments that accumulate into a releasable Product (the broader, user-facing capability). This distinction helps align day-to-day development with business outcomes: every increment should be a cohesive slice of the evolving solution that is demonstrably usable or verifiable, while the Product view ensures that increments collectively support release goals and benefits realization. AgilePM’s focus on MoSCoW prioritization and timeboxing supports this by ensuring each Solution Increment contains the right mix of Must/Should/Could features to satisfy acceptance and maintain momentum. In practice, reviews showcase the Solution Increment’s usability to business representatives, while release planning considers how these increments roll up into Product evolution. Therefore, the two types associated with what is delivered are best captured by Solution and Product, making option A the fit with AgilePM terminology and intent.

Statement 1: Correct. Identifying stakeholders involves analyzing who will be impacted by the change and their level of influence.

Statement 2: Correct. Stakeholder mapping is a tool used to visualize and prioritize stakeholders based on their influence and interest.

Key AgilePM Concepts Referenced:

Stakeholder Mapping and Identification: AgilePM Handbook, Chapter 5, Section 5.5.

It is during the Feasibility phase that it is first established whether further investigation of the project is justified3. This phase aims to determine if the proposed project is likely to be feasible from both a technical and business perspective.

The Business Consortium’s description of Business Agility emphasizes a progressive, people-centric approach. While tools and technology matter, agile ways of working prioritize empowered people, fast feedback, learning, and adaptive leadership across all business functions—not just IT. A people-centric stance enables rapid sensing and responding to change, closer customer collaboration, and continuous improvement of value streams. It underpins practices such as cross-functional teams, decentralized decision-making, iterative planning, and outcome-based metrics. Options like “strategic focused,” “technology focused,” and “collaborative” reflect important aspects of agility, but the defining adjective used in the Consortium’s phrasing is people-centric, capturing the primacy of culture, leadership behaviors, and human interactions in achieving genuine business agility.

Minimum Viable Product (MVP): An MVP allows early customers to use a product and provide valuable feedback, which is then incorporated into subsequent iterations. This is central to Agile practices, emphasizing incremental delivery and responsiveness to user needs.

Other Options:

B: Full transparency relates to visibility into processes and progress, not product development.

C and D: These refer to team dynamics, not product delivery.

Key AgilePM Concepts Referenced:

Incremental Delivery: AgilePM Handbook, Chapter 3, Section 3.7.

Performing Stage: In this stage, team members work cohesively towards achieving results. Roles and processes are clear, and collaboration is at its peak.

Other Stages:

Forming: Initial setup with limited collaboration.

Storming: Characterized by conflict and role clarification.

Adjourning: Focused on disbanding after tasks are completed.

Key AgilePM Concepts Referenced:

Team Development Models: AgilePM Handbook, Chapter 5, Section 5.4.

Comprehensive and Detailed Explanation (paraphrased from Agile Project Management guidance):

Agile thinking emphasizes customer value, empirical evidence, collaboration, and transparency. Option A reflects progressive elaboration and just-in-time refinement—good agile practice. Option B suggests a typical, lightweight cadence for readiness (often the Sprint prior), which is acceptable when driven by context and team capacity rather than rigid rule. Option C captures the essence of flow through small, frequent, validated increments. Option D, however, bypasses value-based prioritization, team forecasting, and collaborative decision-making by selecting the next Sprint’s work purely on sponsor preference. Agile approaches (e.g., MoSCoW prioritization, product goals, acceptance criteria) rely on shared, objective value measures, not unilateral authority, to maximize outcomes. Therefore, D does not demonstrate agile thinking.

Feedback and Coaching: Sponsors play a critical role in change, and change managers support them by providing feedback and coaching to help them lead effectively. This builds their confidence and ensures alignment with the change vision.

Other Options:

A: Sponsors should prepare the vision themselves.

B: Sponsors themselves lead commitment-building efforts.

D: Protecting sponsors isn’t an effective strategy; engaging them is key.

Key AgilePM Concepts Referenced:

Sponsor Engagement: AgilePM Handbook, Chapter 6, Section 6.2.

Principle 8 - Demonstrate Control requires the transparency of all work being performed by the team5. This principle ensures that plans and progress are visible to all and that progress is measured through the delivery of products rather than completed activities5.

Statement 1: Incorrect. Non-verbal communication refers to gestures, facial expressions, and body language, which cannot be captured in written form.

Statement 2: Correct. Actions, such as behavior during change or leading by example, can convey powerful messages without verbal communication.

Key AgilePM Concepts Referenced:

Non-Verbal Communication in Engagement: AgilePM Handbook, Chapter 4, Section 4.4.

In an agile context, the Scrum Master embodies servant leadership, coaching the team and the organization to apply Scrum effectively. Their accountability is to establish and uphold Scrum’s empirical approach—transparency, inspection, and adaptation—by ensuring events, artifacts, and values are understood and used as intended. They remove impediments that hinder flow, facilitate collaboration with stakeholders, and help the team focus on outcomes guided by the Sprint and Product Goals. Crucially, the Scrum Master does not manage scope, schedule, or approve the technical solution; those duties lie with product ownership and technical leadership. Nor do they “maximize value” directly—that accountability belongs to the Product Owner. Instead, the Scrum Master improves the system of work so the team can deliver value predictably and sustainably, fostering continuous improvement and adherence to agreed quality standards (e.g., Definition of Done). This aligns with option A and distinguishes it from the governance or authority-centric responsibilities implied by the other options.

Key Performance Indicators (KPIs): KPIs are agreed-upon metrics that measure progress against desired outcomes. These indicators are crucial for tracking the effectiveness of change efforts.

Other Options:

A: Islands of stability refer to elements unaffected by change.

C: Incremental milestones are checkpoints but not specific measures of outcomes.

D: Transition tranches are phases of change implementation.

Key AgilePM Concepts Referenced:

Outcome Measurement: AgilePM Handbook, Chapter 7, Section 7.5.