Document Guide
AI Project Charter — Agile
Purpose
An Agile AI Project Charter authorizes an AI initiative and establishes its governance boundaries before the first sprint begins. It is intentionally lighter than a plan-driven charter — it does not try to anticipate every decision upfront — but it must be more explicit about the governance guardrails that apply throughout iterative delivery.
The most common failure mode in agile AI projects is treating governance as a retrospective activity: the team builds, then governance catches up. This charter prevents that pattern. By documenting the AI governance Definition of Done criteria, the Product Owner's accountability for governance obligations, and the backlog change control mechanism before sprint 1 begins, the charter makes governance a built-in property of the delivery process rather than an external check applied at the end.
This is not a heavyweight document — it should be completable in one working session. Its value is in the conversations it forces before work starts, and in the authorization record it creates for the Product Owner and governance stakeholders to reference throughout delivery.
How It Differs from the Plan-Driven Charter
Key Differences
The plan-driven charter establishes phase gates, a RACI matrix, and milestone-based controls. The agile charter establishes sprint governance boundaries, PO accountability, backlog change control, and a governance Definition of Done. It replaces detailed upfront planning with clear constraints and a mechanism for managing change as the project evolves.
Where the plan-driven charter says "here is the complete scope and schedule," the agile charter says "here is what the team is authorized to build, here are the governance constraints that apply to every sprint, and here is how changes to scope are governed." The team still needs a Risk Register, an Impact Assessment, and a Bias & Fairness Assessment — this charter authorizes the initiative and establishes the governance envelope within which those documents are produced.
Where It Fits in Your Document Pack
Position in Sequence
Complete the Agile AI Project Charter before Sprint 1 begins. It authorizes the initiative. The Risk Register and Bias & Fairness Assessment are produced during delivery — this charter establishes the governance obligations they fulfill. The Governance Backlog translates the DoD criteria in this charter into sprint-ready user stories.
The charter's Definition of Done section feeds directly into the Governance Backlog — each DoD item should have a corresponding governance user story in the backlog before the relevant sprint begins. The charter's risk appetite and constraint fields inform how the Risk Register is scoped. Its PO accountability section clarifies who is responsible for governance decisions when the team moves fast.
What This Template Covers
- Charter identification: initiative name, Product Owner, Scrum Master, governance liaison, authorization date, and sprint cadence
- AI system context: what the system does, AI system type, risk level, data scope, intended users, and affected populations
- Initiative vision and goals: the problem being solved, measurable success criteria stated in sprint-deliverable terms, and the out-of-scope boundaries that constrain the backlog
- Governance roles: Product Owner accountability for AI governance decisions, Scrum Master facilitation responsibilities, governance liaison role, and escalation path when governance questions arise mid-sprint
- AI Governance Definition of Done: the minimum governance criteria that must be satisfied before any sprint increment can be considered done — bias testing, risk register update, human oversight confirmation, and others calibrated to the system's risk level
- Sprint governance constraints: what the team is authorized to build without additional approval, and what changes require governance review before the backlog item can be accepted into a sprint
- Backlog change control: the mechanism for managing changes to AI system scope, data sources, model architecture, or deployment context that arise during iterative delivery
- Risk appetite and constraints: the organization's tolerance for AI-specific risks, regulatory boundaries that cannot be crossed, and the conditions under which a sprint must be paused for governance review
- Linked governance documents: the governance deliverables expected during delivery, with the sprint by which each should be initiated
- Authorization and sign-off: Product Owner, engineering/delivery lead, and governance/compliance approval
Framework Alignment
- EU AI Act Art. 9 — Risk management system established before development begins; governance obligations apply throughout the lifecycle, including iterative development
- NIST AI RMF — GOVERN 1.1 & 1.2 — Organizational policies and accountability structures for AI risk management established upfront, including roles and responsibilities
- ISO/IEC 42001 Clause 6.1 — Actions to address AI risks and opportunities planned before AI system development begins
- PMI Agile Practice Guide — Governance of agile projects: lightweight upfront authorization with adaptive planning, empowered Product Owner accountability, and iterative delivery within defined constraints
- OECD AI Principles 1.5 — Accountability: AI actors should be accountable for the proper functioning of AI systems, including through iterative delivery phases
Download
Essential — free for all membersAI Project Charter — Agile — Fillable PDF
Checking access…