AgilePM Foundation · Domain 10 of 10

AgilePM Foundation Domain 10: Governance, compliance and AgilePM products

How AgilePM satisfies governance without losing agility: traditional and agile governance side by side, building regulatory compliance into delivery, and the business case and management products that support financial control.

Exam weight estimate
Not published
Official syllabus topics
3
Estimated questions estimate
~5
Suggested study time estimate
3–4 hrs

About 13 min read Reviewed October 2026

Overview

Governance, compliance and AgilePM products covers how an agile project stays accountable to the organisation that funds it. Traditional governance usually controls projects through stage gates based on documents and detailed up-front approval; agile governance makes decisions on evidence from working solutions, delegates authority within tolerances and keeps controls light. AgilePM is designed to work with both: its lifecycle has natural decision points, at the end of Feasibility, Foundations and each increment, that can align with an organisation's existing gates.

The area also covers regulated environments, where compliance requirements are treated as non-negotiable requirements and built into delivery and the Definition of Done rather than checked only at the end. Finally it covers financial governance: the business case, outlined early, firmed up in Foundations and revisited at increment boundaries, and the AgilePM management products that give sponsors and governance bodies the information they need.

How it's tested

Questions ask how AgilePM fits an organisation's governance, how to handle a regulatory requirement, when the business case is reviewed, or which product serves a governance need. The right answer balances control with agility: decisions at defined points, based on evidence and the business case, with compliance built in.

  • Fit with governance

    An organisation with traditional stage gates is described and you choose how AgilePM aligns with them without abandoning agility.

  • Compliance in delivery

    A regulatory requirement is described and you choose how it should be prioritised and assured during the project.

  • Business case and products

    You choose when the business case is created or revisited, or which management product supports a decision.

Reasoning it through

A question describes a bank whose governance requires gate approval before major spending and asks how an AgilePM project should operate. Ignoring the gates is tempting because agile values working solutions, and so is producing a full specification for the first gate. AgilePM aligns its own decision points, such as the end of Foundations and each increment, with the gates, giving governance evidence and a current business case.

Syllabus topics 3

Official syllabus topics from the APMG International outline, in outline order.

10.1 Traditional vs agile governance and how AgilePM supports bothDocument-driven gates versus evidence-based decisions, and how AgilePM bridges them.
What it means
Traditional governance controls projects through sequential gates that approve detailed plans and documents before work proceeds. Agile governance delegates authority within tolerances and makes decisions based on working output and an up-to-date business case. AgilePM supports both by providing defined decision points and products that can satisfy existing gates.
What to understand
The end of Feasibility, the end of Foundations and the end of each increment are natural governance points. At these points governance sees evidence of value delivered and a refreshed business case, rather than only documents describing intentions.
How it shows up
An organisation with traditional governance is described and you choose how the AgilePM project should engage with it.
Common confusion
Assuming agile projects must either bypass governance or adopt full document-driven gates; AgilePM aligns its decision points with them.
10.2 Regulatory and compliance considerations in agile projectsTreating compliance as a requirement built into delivery, with evidence produced as you go.
What it means
In regulated environments, compliance requirements such as legal, safety, data protection or audit obligations must be met regardless of other priorities. In AgilePM they are captured as requirements, typically Must Haves or non-functional requirements, and built into acceptance criteria and the Definition of Done.
What to understand
Compliance evidence and documentation that regulators need is part of the value the project delivers, so it is produced incrementally rather than left to the end. Involving compliance specialists early, for example as advisers, reduces the risk of late rework.
How it shows up
A regulatory requirement is introduced and you choose how to prioritise and assure it, such as classifying it as a Must Have and adding it to the Definition of Done.
Common confusion
Thinking agile is unsuitable for regulated work, or that compliance can be checked once just before go-live.
10.3 Financial governance and AgilePM products that support itThe business case through the lifecycle and the products that inform decisions.
What it means
The business case justifies the investment: it is outlined in Feasibility, firmed up in Foundations and revisited at increment boundaries, with benefits assessed after deployment. AgilePM defines management products, such as terms of reference, the business case, the prioritised requirements, the delivery plan, review records and a benefits assessment, that give governance the information it needs.
What to understand
With fixed time and cost, financial control focuses on whether continuing still makes business sense and whether value is being delivered, rather than on approving changes to scope. Products are produced at the formality the project needs and many evolve as the project progresses.
How it shows up
You choose when the business case is reviewed or which product supports a funding decision at an increment boundary.
Common confusion
Treating the business case as a one-off approval document that is never revisited.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Traditional governance

    Control through sequential gates that approve detailed plans, specifications and documents before the next stage proceeds.

    Remember
    AgilePM can align with these gates rather than bypass them.
    Tested as
    Fit-with-governance questions.
    Trap
    Concluding that agile projects must ignore existing gates.

  • Agile governance

    Governance that delegates authority within tolerances and decides based on evidence from working solutions and a current business case.

    Remember
    Fewer, better-informed decisions rather than more documents.
    Tested as
    Comparison and best-approach questions.
    Trap
    Equating agile governance with no governance.

  • Natural decision points

    The ends of Feasibility, Foundations and each increment are points where governance can decide whether to continue, change direction or stop.

    Remember
    Align these with the organisation's gates.
    Tested as
    When-should-governance-decide questions.
    Trap
    Placing governance decisions inside every Sprint.

  • Business case through the lifecycle

    Outlined in Feasibility, firmed up in Foundations, revisited at increment boundaries, with benefits assessed after deployment.

    Remember
    It is a living justification, not a one-time approval.
    Tested as
    Timing questions about the business case.
    Trap
    Treating the approved business case as final.

  • Business Sponsor and governance

    The Business Sponsor owns the business case and is the main link between the project and the organisation's governance.

    Remember
    Funding decisions are business decisions.
    Tested as
    Who-decides questions on funding.
    Trap
    Giving funding decisions to the Project Manager.

  • Compliance as a requirement

    Legal, regulatory and audit obligations are captured as requirements, usually Must Haves or non-functional requirements, so they cannot be traded away.

    Remember
    If omitting it would be illegal, it is a Must Have.
    Tested as
    Classification of regulatory needs.
    Trap
    Classifying a regulatory requirement as a Should or Could Have.

  • Compliance in the Definition of Done

    Building compliance checks and evidence into acceptance criteria and the Definition of Done means each increment is compliant when it is done.

    Remember
    Continuous compliance, not a final audit scramble.
    Tested as
    How-to-assure-compliance questions.
    Trap
    Leaving all compliance work to a final phase.

  • Products at the right formality

    AgilePM management products can be documents, models, boards or conversations recorded briefly, depending on the context and governance needs.

    Remember
    Produce what governance genuinely needs, no more and no less.
    Tested as
    Questions on documentation level.
    Trap
    Choosing either no documentation or exhaustive documentation.

  • Evolving vs. point-in-time products

    Some products, such as the business case and prioritised requirements, evolve throughout the project; others capture a decision or review at one point.

    Remember
    Evolving products are kept current, not frozen.
    Tested as
    Questions on how products are maintained.
    Trap
    Baselining an evolving product as if it were final.

  • Benefits assessment

    After deployment, the business assesses whether the benefits in the business case are being realised, closing the loop on financial governance.

    Remember
    Benefits are judged after the solution is in use.
    Tested as
    Financial governance timing questions.
    Trap
    Declaring benefits achieved at project closure.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Traditional vs. agile governance

ConceptMeaningKey differenceCommon trap
Traditional governance Sequential gates approving detailed documents Decides on plans and promises before work Assuming AgilePM cannot operate under it
Agile governance Delegated authority within tolerances, evidence-based decisions Decides on working output and a current business case Reading it as no governance
AgilePM approach Defined decision points aligned with organisational gates Bridges both with right-sized products Choosing either extreme

Compliance built in vs. compliance checked at the end

ConceptMeaningKey differenceCommon trap
Built in Compliance as requirements, acceptance criteria and Definition of Done Each increment is compliant when done Assuming it slows delivery unacceptably
Checked at the end Compliance review just before go-live Problems found late cause rework and delay Thinking it is the agile default

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Ignore the gates

    What candidates pick
    Tell governance the agile project will report through Sprint Reviews instead of its gates.
    Why it looks right
    Sprint Reviews show working output, which agile values.
    Why it's wrong
    AgilePM works with organisational governance by aligning its decision points with existing gates, providing evidence and a current business case.

    Clue to watch for An organisation with mandatory approval gates.

  2. Full specification for the gate

    What candidates pick
    Produce a complete detailed specification to pass the first gate.
    Why it looks right
    It satisfies a document-driven gate.
    Why it's wrong
    AgilePM keeps requirements high-level early; it provides products at the formality governance genuinely needs, not a full specification.

    Clue to watch for A gate early in the lifecycle asking for justification.

  3. Regulation as a Should Have

    What candidates pick
    Classify a new data protection requirement as a Should Have because a deadline is tight.
    Why it looks right
    It protects other features.
    Why it's wrong
    Without it the solution would be unlawful, which makes it a Must Have by definition.

    Clue to watch for A legal or regulatory obligation in the stem.

  4. Compliance at the end

    What candidates pick
    Schedule a compliance review in the final Sprint before deployment.
    Why it looks right
    It concentrates compliance effort in one place.
    Why it's wrong
    Building compliance into acceptance criteria and the Definition of Done avoids late discovery and rework.

    Clue to watch for A regulated environment and a question on when to assure compliance.

  5. Business case approved once

    What candidates pick
    Leave the business case unchanged after Foundations approval.
    Why it looks right
    Approval feels like the end of the business case's job.
    Why it's wrong
    The business case is revisited at increment boundaries to confirm the project is still justified, and benefits are assessed after deployment.

    Clue to watch for An increment boundary or a significant change in costs or benefits.

Answer framework

Use these steps when a question involves governance, regulation or funding decisions.

  1. Identify the governance need in the scenario: approval to proceed, assurance of regulatory compliance, or a funding or business-case decision.
  2. Align with existing governance by using AgilePM's natural decision points at the end of Feasibility, Foundations and each increment.
  3. Base decisions on evidence, such as deployed or demonstrated increments, and on a current business case rather than on document volume.
  4. Treat legal and regulatory obligations as Must Haves, build them into acceptance criteria and the Definition of Done, and produce compliance evidence incrementally.
  5. Choose products at the formality the context needs, keep evolving products current, and route funding decisions to the Business Sponsor.

Practice question

An AgilePM project has just deployed its first increment. The organisation's governance board must decide whether to fund the next increment. What should primarily inform this decision?

Want more like this? The AgilePM Foundation practice test has questions for every domain.

Checklist

0 of 12

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Study this area last, because it draws on roles, the lifecycle, MoSCoW and management by exception. Start by drawing the lifecycle again and marking the governance decision points at the end of Feasibility, Foundations and each increment. Beside each, note what governance sees: the business case at its current maturity and the evidence available at that point.

Next, work through compliance. Take two regulatory obligations, such as data protection and an audit trail, and show how each becomes a Must Have, an acceptance criterion and part of the Definition of Done. This makes the built-in approach concrete and prepares you for regulated-environment scenarios.

The underestimated topic is the business case as a living product. Practise explaining how it changes from outline to firm to revalidated, and why benefits are assessed after deployment.

Finally, review the main management products and the principle of right-sized formality. Then take a full mock exam, since governance questions often combine several areas, and review each miss by asking which decision point and which role the scenario involved.

FAQ

Can AgilePM work in an organisation with traditional stage gates?

Yes. AgilePM is designed to align its decision points, such as the end of Foundations and each increment, with existing gates, providing evidence and a current business case.

Does agile governance mean less control?

No. It means control based on evidence and delegated authority within tolerances, with fewer but better-informed decisions, rather than control through documents alone.

How should regulatory requirements be prioritised?

As Must Haves, because without them the solution would be unlawful. They should also be built into acceptance criteria and the Definition of Done.

When is the business case reviewed?

It is outlined in Feasibility, firmed up in Foundations and revisited at increment boundaries or when costs or benefits change significantly. Benefits are assessed after deployment.

Does AgilePM require a lot of documentation?

It defines management products, but they are produced at the formality the context needs. In regulated settings that may be more formal; elsewhere it can be lighter.

Who makes funding decisions on an AgilePM project?

The Business Sponsor, who owns the business case, together with the organisation's governance bodies.

Other Project Management certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 10 knowledge

You have covered traditional and agile governance, compliance in agile projects and the business case and products that support financial control. Check that you can choose the balanced, evidence-based answer in governance scenarios.

Take the AgilePM Foundation practice test Check your AgilePM Foundation readiness

Keep going