- Agile doesn’t eliminate the need for a project charter — it changes the form. The inception deck, team charter, and iteration 0 outputs together do what a conventional charter does in plan-driven work. For an AI project, the question isn’t whether to answer the governance questions, but when. Some of them must be answered before sprint 1, because they determine the architecture and the data pipeline, not the backlog.
- The EU AI Act and NIST AI RMF have no methodology preference. Human oversight must be designed in from the start, data governance must be established before training, affected parties must be identified before design. These are architecture prerequisites. A sprint team that hasn’t answered them isn’t moving faster — it’s accumulating governance debt.
- Agile teams have a structural blind spot for the questions that matter most in AI governance. Sprint reviews surface working features. They don’t surface whether training data is representative of the deployment population, whether affected communities have been engaged, or whether the system has a tested circuit breaker. These need explicit owners and explicit ceremonies — they don’t emerge from velocity.
- Governance debt in AI is more expensive than technical debt. A refactored architecture can usually be shipped. Bias embedded in training data may require taking the system offline, discarding the dataset, and restarting the data pipeline. The cost of answering the AI charter questions at inception is always lower than the cost of answering them mid-sprint or post-deployment.
- From an AIGP and PMI-ACP perspective, the synthesis is this: agile methodology decides how the work gets done; AI governance decides what work must be done. They are not in conflict. A team that understands both can move fast and govern well simultaneously.
“We don’t do big design up front.” It’s the most common objection when a governance-minded PM mentions the charter to an agile team. And it’s not wrong — agile methodology is built on the insight that detailed upfront planning in complex domains often produces elaborate documentation that the first sprint makes obsolete.
But there’s a distinction worth drawing. Design decisions — how the user interface works, what the data model looks like, how microservices communicate — can often be deferred and revised. Governance decisions about who is accountable for what, what the system is permitted to do, and who might be harmed if it does it wrong cannot always be deferred without consequence. Some of those decisions determine the architecture. Others shape the data pipeline. Still others define whether the system is legally deployable at all.
The agile AI PM who skips the charter isn’t eliminating governance. They’re deferring it to a moment when it will cost more to answer, be harder to change, and arrive too late to prevent the decisions that matter most.
What Agile Actually Calls It
The objection “we don’t do project charters” often means: we don’t do a 40-page waterfall document. It rarely means: we have no shared understanding of why we exist, what we’re building, and who is accountable for what. Every functioning agile team has something that performs the charter function. It just goes by different names.
| Agile Artefact | Charter Function It Serves | What It Typically Misses for AI |
|---|---|---|
| Inception Deck | Answers the ten questions every project team needs to answer before writing a line of code: why are we here, the elevator pitch, the product box, what’s in and out of scope, the neighbours, what keeps us up at night, sizing, the solution, the priority. Popularised by Thoughtworks. | The AI-specific questions: Why AI rather than a simpler approach? Who might be harmed? What data governance is required? What oversight is mandatory before this system is deployable? |
| Team Charter / Social Contract | Establishes team norms, working agreements, communication protocols, and decision rights within the team. Answers: how do we work together? | Answers nothing about why the project exists, what the system is permitted to do, or who outside the team is affected by its outputs. |
| Iteration 0 / Sprint 0 | Setup sprint before development begins: environment provisioning, architecture decisions, initial backlog refinement, Definition of Ready establishment. Answers: are we technically ready to sprint? | Often rushed and treated as overhead. AI governance questions — data access, oversight design, regulatory classification — are rarely addressed explicitly in sprint 0 and fall into the backlog or disappear. |
| Definition of Ready | The conditions a user story must meet before it can enter a sprint. Answers: is this story ready to be worked on? | Operates at the story level, not the project level. Cannot capture system-level governance decisions that need to be made once and held firm across all sprints. |
| PI Planning (SAFe) | Program Increment planning session across multiple agile teams. Establishes features, team objectives, and dependencies for a multi-sprint increment. Answers: what are we building over the next 10–12 weeks? | Focuses on delivery planning, not governance. AI-specific architecture constraints, regulatory requirements, and affected party considerations are rarely PI Planning inputs unless they have been explicitly established earlier. |
None of these artefacts is wrong. None of them, alone or in combination, answers the AI-specific governance questions that must be resolved before the first sprint. That’s the gap the AI project charter fills — in whatever form fits the team’s methodology.
Why Some Governance Can’t Be Iterative
Agile works by embracing change: build a little, learn a little, adapt. That principle is sound for features. For certain categories of AI governance decision, it isn’t.
Consider data. If you begin sprint 1 with a training dataset that wasn’t properly examined for bias, you don’t discover that in sprint 3 and fix it with a minor refactor. You discover it when the model is already trained on that data. EU AI Act Article 10 requires bias examination before training begins, not as a retrospective activity. A team that treats data governance as an iterative concern will find that “we’ll fix it later” means “we’ll retrain the model” — a very different kind of later.
Consider oversight architecture. EU AI Act Article 14 requires that high-risk AI systems be designed from the start to support five specific oversight capabilities: understanding system limitations, detecting anomalies, correctly interpreting outputs, overriding decisions, and halting the system. These are not features you add in a later sprint. They are constraints on the architecture that, if not specified before development begins, require expensive rework to incorporate.
Consider affected party identification. NIST AI RMF MAP 1.2 requires engagement with potentially impacted communities. This isn’t a task that appears in sprint 8. The affected party mapping shapes the testing strategy, the fairness metrics, the feedback mechanism design, and the FRIA. If it hasn’t happened before sprint 1, the design decisions that depended on it have already been made without it.
| Governance Decision | Why It Can’t Be Deferred | Cost of Deferral |
|---|---|---|
| Data governance and bias examination | Must be complete before training begins. EU AI Act Article 10(2) requirements apply to data selection, not model output. | Model retraining. Possible legal non-compliance. Dataset may need to be discarded and rebuilt. |
| Human oversight architecture | Determines the system architecture. Override mechanisms, circuit breakers, and logging are design-time requirements, not features. | Architectural rework mid-project. Systems designed for full automation are structurally difficult to retrofit for meaningful oversight. |
| Affected party identification | Shapes testing strategy, fairness metrics, feedback mechanism, and FRIA. All of these are design inputs, not retrospective activities. | Testing that doesn’t cover the right populations. Fairness metrics that don’t measure what matters. A FRIA that can’t be completed because the design didn’t anticipate it. |
| Regulatory classification | Determines the compliance pathway and the full list of required deliverables. High-risk systems require activities — conformity assessment, technical documentation, registration — that must be planned from day one. | Compliance activities discovered late are expensive to retrofit. Some — like conformity assessment — are gating requirements that can delay deployment. |
| Go/no-go on the AI approach itself | NIST AI RMF MAP 1.5 identifies this as an explicit decision point. A team that hasn’t made this decision explicitly has made it implicitly by starting to build. | Sunk cost makes an honest assessment harder the longer it is deferred. The cost of stopping after three sprints is much higher than the cost of stopping before sprint 1. |
The Lightweight Agile AI Charter
The agile AI charter is not a 40-page waterfall document. It is the minimum set of answers that lets the team sprint safely, without accumulating governance debt that will stop the project later.
The right format is whatever your team will actually complete and maintain. For many agile teams, that means framing it as an extended inception deck — the original ten questions plus seven AI-specific additions. For SAFe teams, it may mean a governance addendum to the PI Planning artefacts. For Scrum teams, it may mean a governance section in the team charter. The form matters less than the substance.
The Seven Questions That Must Be Answered Before Sprint 1
These are the AI governance questions that determine architecture, data strategy, and legal deployability. They cannot be placed in the backlog and answered iteratively.
| Question | Why Before Sprint 1 | Where It Lives in Agile |
|---|---|---|
| Why AI rather than a rules-based or simpler approach? What trade-offs are being accepted? | NIST MAP 1.1 go/no-go gate. If the answer isn’t clear, starting to build is the wrong response. | Inception deck — “Why are we here?” section, extended for AI. |
| What level of human oversight is required, and what does that mean for the architecture? | Determines the system design before any code is written. Human-in-the-loop changes the interface, workflow, and latency requirements. | Architecture decision record (ADR) or inception deck technical section. |
| What data will train the system, and is it ready for AI training under Article 10? | Data governance is a prerequisite to training. It cannot be completed iteratively — it must be done before the data pipeline is built. | Data ADR or dedicated data governance spike in iteration 0. |
| Who is subject to this system’s outputs (not just who uses the system)? | Shapes testing strategy, fairness metrics, and feedback mechanism design. All of these are early design inputs. | Inception deck — “Who are our neighbours?” section, extended for affected parties. |
| What is the system’s EU AI Act risk classification? | Determines the full compliance pathway and required deliverables. High-risk activities must be planned and resourced from day one. | Compliance spike in iteration 0; output feeds backlog and project budget. |
| Who can halt this system in a production incident, and what is the mechanism? | A circuit breaker that has never been designed cannot be deployed to production. This is an architecture constraint, not a feature. | ADR in iteration 0. Test case in acceptance criteria for deployment readiness. |
| What are the success criteria beyond accuracy — including fairness, robustness, and explainability? | These define the Definition of Done at the system level. Without them, the team cannot determine when the project is complete. | Inception deck — “What keeps us up at night?” section, extended for AI dimensions. |
Questions That Can Be Distributed Across the Lifecycle
Not every AI governance question needs to be answered before sprint 1. Some are appropriately addressed incrementally, as long as they have named owners and appear in the backlog.
| Question | When to Address | How to Track |
|---|---|---|
| Detailed fairness testing across all demographic subgroups | Before deployment. Test data and methodology defined early; results produced as the model matures. | Epic in backlog: “Fairness validation”. Definition of Done for deployment readiness. |
| Full technical documentation for EU AI Act Article 11 | Built iteratively across sprints; completed before conformity assessment. | Ongoing documentation spike. Owner named at inception. Gates deployment. |
| Detailed monitoring plan and thresholds | Before deployment. Monitoring architecture defined early; thresholds calibrated against model behavior as it develops. | Epic in backlog: “Production monitoring readiness”. |
| User feedback and contestation mechanism | Designed before deployment. Can be built incrementally in later sprints. | User story in backlog with Definition of Ready: affected party mapping complete. |
| Fundamental Rights Impact Assessment (Article 27) | Initiated at chartering based on affected party mapping; completed before deployment. | Project milestone. Owner named at inception. Not a backlog item — a gate. |
Governance Debt: The Agile Team’s Blind Spot
Technical debt is a concept agile teams understand well: shortcuts taken now that create rework later. Governance debt works the same way, but the rework is more expensive and less predictable.
Consider what happens when an agile AI team defers the affected party mapping to “later.” Sprint 1 begins. The team builds a data pipeline based on available data. Sprint 2, the model training begins. Sprint 3, initial model evaluation looks promising on aggregate metrics. Sprint 6, someone finally asks: have we tested this against the populations who might be disproportionately affected? The answer reveals that those populations were underrepresented in the training data. The model has learned patterns that don’t generalise to them. The fix is not a refactor — it is a data problem, which means going back to the data pipeline, which means going back to sprint 1.
The Agile Manifesto values responding to change over following a plan. That principle holds. But it was written for software product requirements, not for the legal and ethical obligations that apply to AI systems. The EU AI Act does not respond to change by accepting that you intended to implement Article 10 compliance in a later sprint. NIST AI RMF does not treat go/no-go decisions as retrospective activities. These are not changing requirements — they are fixed obligations that must be planned for from the start.
The PMI-ACP Body of Knowledge is clear that agile governance is governance nonetheless. The AIGP Body of Knowledge is equally clear that AI governance obligations attach to the AI system, not to the methodology used to build it. A scrum team building a high-risk AI system has the same obligations under EU AI Act Article 9 as a waterfall team. The methodology determines the sprint cadence, not the compliance pathway.
How to Run an Agile AI Charter Session
The agile AI charter session doesn’t need to be a multi-day planning exercise. For most teams, a half-day session in iteration 0 is sufficient — structured around the seven must-answer questions, with the outputs feeding the inception deck and the backlog.
Before the Session
Identify the product owner, the technical lead, a data representative, and — where possible — someone with regulatory knowledge or access to legal counsel. The session will surface decisions that require authority beyond the development team. Escalation paths should be established before the session, not as an output of it.
Pre-read: the EU AI Act risk classification criteria for your likely use case (Annex III and the prohibited practices in Article 5). If you don’t know whether your system is high-risk, that question needs to be answered in the session.
During the Session
Work through each of the seven must-answer questions in turn. For each one, the goal is a documented answer — not perfect, but sufficient to inform the architecture decisions and backlog structure that follow. If the team cannot answer a question, that is itself a governance signal: either the question needs more research (time-boxed spike in iteration 0) or it reveals a go/no-go issue that must be escalated before development begins.
Use the whiteboard or a shared doc. Capture the answers in writing. The output of the session is the agile AI charter — a lightweight document (one to three pages) that records what was decided, what was deferred and to when, and who owns each open question.
After the Session
Translate governance artefacts into backlog items. Compliance activities — technical documentation, FRIA, fairness testing, monitoring plan — should appear as epics with owners. Architecture decisions from the session should be recorded as ADRs and referenced in the Definition of Ready for the stories they constrain.
Governance debt that was knowingly incurred — questions deferred because they required more research — should be tracked explicitly. Not in a risk register that no one reads, but in the backlog as first-class work items with definitions of done and sprint assignments.
A Note on AI Governance and Agile Ceremonies
Agile ceremonies can absorb AI governance activities if they are designed to. Sprint reviews can include a governance health check alongside the demo. Retrospectives can surface governance debt alongside technical debt. The Definition of Done can include governance acceptance criteria alongside functional ones.
What agile ceremonies cannot do is generate governance decisions that were never made. A sprint review that asks “does the system meet its fairness criteria?” can surface a problem — but only if the fairness criteria were defined. A retrospective can surface the fact that the affected party mapping was never done — but by the time that surfaces in retrospective, the design decisions that depended on it have already been made.
The agile AI charter is not about adding process. It’s about ensuring that the governance decisions that cannot be deferred are made at the point when they are cheapest to make — before sprint 1 — so that everything that follows can actually be agile.
Right-Sizing for Your Team
The right level of formality depends on the system’s risk level, the team’s regulatory context, and the organisation’s AI governance maturity. A low-risk internal tool built by a small team needs a lighter charter than a high-risk system deployed to external users in a regulated sector.
You don’t have AI governance processes yet. Run a half-day inception session before sprint 1 structured around the seven must-answer questions. Write down the answers — even informally. Identify what you don’t know and put it in the backlog as time-boxed spikes with owners. That’s your minimum viable agile AI charter. Resist the temptation to start the first sprint before the data governance question is answered.
You have agile delivery processes but are still building AI governance practice. Formalise the agile AI charter as a standard iteration 0 artefact. Extend your Definition of Done to include governance acceptance criteria at the system level — fairness validation, monitoring readiness, oversight mechanism tested. Track governance debt explicitly in the backlog alongside technical debt. Build a compliance spike into every PI Planning cycle that carries AI deliverables.
Your organisation runs multiple AI initiatives on agile methodologies. Create a standard agile AI charter template that teams complete in iteration 0, mapped to your regulatory obligations and internal AI governance policies. Define portfolio-level governance gates that AI projects must clear before scaling — regardless of methodology. Build FRIA initiation and conformity assessment planning into the standard project intake process, not into the backlog.
The AI Governance Advisor can help your team work through the seven must-answer questions, identify your EU AI Act risk classification, and produce an agile AI charter structured for your methodology and risk level.
AIPMO’s AI Project Charter template includes an agile variant covering the lightweight charter format described in this article — structured as inception deck questions with AI governance additions, mapped to Scrum, SAFe, and hybrid delivery contexts. It includes a governance debt tracker and a sprint-ready checklist for distributing charter questions across the lifecycle. Download free and adapt to your team, or use the AI Governance Advisor to generate a version pre-populated for your methodology, system type, and risk level.
Framework References
EU AI Act (2024) — Article 9 (risk management system as a continuous iterative process, applicable regardless of delivery methodology); Article 10(2) (data governance requirements apply before training begins); Article 14 (human oversight capabilities are architecture requirements, not features); Article 26(2) (named oversight persons with competence, training, and authority must be assigned before deployment); Article 27(1) (Fundamental Rights Impact Assessment).
NIST AI RMF 1.0 (NIST AI 100-1, 2023) — MAP 1.1 (go/no-go decision before development; net benefit analysis including non-AI alternatives; applies regardless of delivery methodology); MAP 1.2 (engagement with affected communities is a design input, not a retrospective activity); MAP 1.5 (go/no-go decision explicit outcome of the MAP function).
PMI Agile Practice Guide (2017) — Governance in agile environments; the distinction between project governance (what must be decided) and delivery approach (how work is organised). Agile governance is governance nonetheless.
PMI-ACP Examination Content Outline — Domain II (Value-Driven Delivery): defining value includes non-functional requirements and risk management. Domain V (Adaptive Planning): planning is not eliminated in agile, it is distributed across the lifecycle appropriately.
AIGP Body of Knowledge v1.0.0 — Domain III (AI Governance Program Design and Implementation): governance obligations attach to the AI system and its deploying organisation, not to the methodology used to build it.
This article is part of AIPMO’s PM Practice series. See also: The AI Project Charter | AI Risk Registers | Human Oversight in AI Systems