Template by Methodology
The Scrum Guide does not mention charters. That does not mean Scrum teams skip them. The lightweight authorising document below covers what the Scrum Guide requires (Product Goal, Sprint cadence, Definition of Done) plus the budget and sponsor sign-off the Scrum Guide deliberately leaves to your organisation.
The Scrum Guide is a framework, not a complete project management methodology. It is explicit that "Scrum is purposefully incomplete" (the Guide's phrasing). What the Guide leaves out is exactly what a charter provides: a sponsor-approved budget envelope, a documented Product Goal, named decision authority on scope boundaries, and a shared understanding of what "done" means. Teams that skip this step routinely find themselves three Sprints in with a backlog that has grown faster than the team can deliver, a sponsor expecting a feature that was never in scope, or a finance partner cancelling the team because nobody told them how long the project would run.
The Scrum project charter solves these problems without breaking the Scrum framework. It is authored in Sprint 0 (one to two weeks before Sprint 1) and is treated as a living artefact that the Product Owner updates whenever the Product Goal shifts.
Every section of a PMBOK-style charter has a Scrum equivalent. The vocabulary changes, but the function is preserved.
| Traditional Charter Section | Scrum Equivalent | What changes in practice |
|---|---|---|
| Project Purpose | Product Goal | The Product Goal is the long-term objective for the Scrum Team. Multiple Sprints contribute toward it. |
| Success Criteria | Definition of Done (DoD) | The DoD is a quality standard. Outcome metrics (adoption, retention) live in the Product Goal, while the DoD governs increment quality. |
| Scope Boundaries | Sprint 0 Initial Backlog + DoR | Sprint 0 produces the initial Product Backlog and Definition of Ready. These bound what the team will pull into Sprints. |
| Decision Authority | Product Owner (PO) authority | The Scrum Guide is explicit: the PO is one person and is accountable for value. No committee replaces the PO. |
| Budget | Team capacity for N Sprints | Budget in Scrum is denominated in Sprints, not dollars. A team of 7 running 6 two-week Sprints is the budget. |
| Milestones | Sprint Goals + Release plan | Each Sprint has a single Sprint Goal. Release planning groups Sprints into shippable increments. |
| Risk Register | Sprint Retrospective backlog of impediments | Scrum surfaces risk continuously via the Sprint Review and Retrospective rather than pre-cataloguing it. |
Sprint 0 is not part of the Scrum Guide. It is widely used in practice to handle the up-front work the Guide leaves to the organisation. The seven activities below produce everything the charter needs.
Author the Product Goal
Owner: Product Owner with stakeholders
Output: One paragraph the entire team can recite
Draft initial Product Backlog
Owner: PO with engineering lead
Output: 30 to 60 stories, T-shirt sized, with the top 12 to 15 ready for refinement
Agree on Sprint length
Owner: Scrum Team (PO, SM, devs)
Output: Either 1, 2, 3, or 4 weeks; commit to one length for the duration
Write Definition of Ready
Owner: Scrum Team
Output: Checklist a story must meet to enter Sprint Planning
Write Definition of Done
Owner: Scrum Team
Output: Checklist an increment must meet to be considered Done
Establish team working agreement
Owner: Scrum Team
Output: Core hours, communication norms, code review and pairing expectations
Set up tooling and CI
Owner: Engineering lead
Output: Repo, branch strategy, CI pipeline, test runners, deployment pattern
A real-shape example. Numbers reflect a typical mid-size B2C mobile product rebuild, drawn from the metrics range Atlassian publishes in its Agile project management guides.
Rebuild the Aurora customer mobile app as a native iOS and Android experience that lifts 30-day retention from 41% to 60% and reduces session crash rate from 1.8% to under 0.4% by end of Q4 2026.
2 weeks (6 sprints planned, ending 19 December 2026)
7 (1 PO, 1 SM, 5 devs including 2 iOS, 2 Android, 1 backend integration)
USD 612K (team cost for 12 weeks plus app store, analytics tooling, and 1 external accessibility audit)
In scope (Sprint 1 to 6): Account dashboard, transactions list, payments flow, biometric login, push notification preferences, accessibility audit at WCAG 2.2 AA, app store submission and review response.
Out of scope: Do not rebuild the merchant-side admin app (separate cohort). Do not migrate the auth backend (handled by platform team in parallel). Do not include the rewards module (Sprint 7+ if greenlit). Do not localise beyond US English at v1.
Naming a steering committee as decision authority.
The PO is one person. A steering committee with veto authority is a PRINCE2 Project Board, not Scrum. If your governance requires a committee, run hybrid or PRINCE2 instead of pretending it is Scrum.
Committing to a feature list as scope.
Scope is the Product Goal plus boundary statements. A fixed feature list defeats the variable-scope premise of Scrum and turns the project into waterfall in Scrum costume.
Skipping the Definition of Done.
The Scrum Guide names the DoD as a required commitment for the Increment. Without it, "done" means whatever the developer wants it to mean that day. Two Sprints in, the increment will be untestable.
Putting a dollar-denominated budget on a feature list.
Budget in Scrum is N Sprints of team capacity. Trying to attach dollar amounts to specific features turns every Sprint Review into a budget reconciliation argument.
Related on this site
Updated 2 May 2026