Agile Team Charter: What to Include in a Template

A common document used by agile teams is the agile team charter. This describes why the team exists, what its goals are, who is responsible for what, and how the team will operate. It helps team members to align expectations, establish team norms, clarify roles and responsibilities, and make decisions together.

An active agile team charter will include the team’s mission, vision, success criteria, values, roles and responsibilities, working agreements, Definition of Done, communication rules, decision-making methods, stakeholders, and dependencies. It can be created collaboratively by teams in a workshop and revised as goals, membership, or working conditions change.  

An agile team charter is not a project plan; it’s a living reference. It promotes shared accountability without restricting the team’s agility.

Key Highlights of Agile Team Charter

• Purpose: It states the reason for the team’s existence and the value it intends to provide.
• Vision and goals: Describes the desired end result and how the team will know it is successful.
• Team norms: Sets expectations around communication, collaboration, respect, and accountability.
• Roles and responsibilities: Determines who owns individual decisions, activities, and deliverables.
• Working agreements: Practical rules for meetings, feedback, conflict resolution, and day-to-day collaboration.
• Definition of Done: The quality criteria that the work must meet to be considered complete.
• Stakeholder alignment: Understands key stakeholders, dependencies, and communication expectations
• Collaborative creation: Engages the team in developing and agreeing on its charter.
• Continuous improvement: Promotes the idea of regular reviews and updates, rather than treating the charter as a one-time document. 
• Practical resource: An agile team charter template helps teams capture these agreements in a clear, reusable format.

Introduction

How can a brand-new team go from perfect harmony on Monday to complete operational chaos by Friday? And nobody even did anything wrong! To understand this, let us take a hypothetical example.

A new team forms on Monday. By Friday, two developers disagree on how reviews should work, the designer does not know who approves changes, and the Product Owner assumes everyone attends the same meetings. Nobody did anything wrong. The team simply never talked about how it wanted to work.

That is the gap an agile team charter fills. It turns the unspoken assumptions people carry into a few pages the whole team can read, challenge, and change.

This step-by-step roadmap explains what an agile team charter is, when to create one, and which elements to include. You will learn how to create an agile team charter step by step and see a filled-in example. It also provides a free template, the benefits, the Scrum Master's role, and common mistakes. If you are still forming the group itself, start with  how to build an agile team, then return here to write the charter.

What Is an Agile Team Charter?

An agile team charter is a document collaboratively produced by a team that describes the team’s purpose, shared goals, team operating principles, and responsibilities and agreements about how the team will work together. It gives team members a common frame of reference for making decisions, resolving disputes, and coordinating work. It is different from a project charter, which authorizes a project and sets its budget, scope and sponsor.

The  Agile Alliance’s statement on project chartering  highlights the need to document objectives, scope boundaries, and agreements between the team and external stakeholders. The  Agile Practice Guide  also says that Agile teams need a common purpose for the project and clarity on how they will work together.

An agile team charter applies this concept in the actual work environment of the team. For instance, a product development team might agree to review pull requests within one working day, quickly flag blockers, and involve the Product Owner if acceptance criteria are still unclear. These agreements clarify expectations. The team builds a common approach rather than individual assumptions.

These agreements make expectations explicit. Instead of relying on individual assumptions, the team establishes a common approach.

Definition and Purpose

The purpose of a charter is alignment. People join teams with different habits, expectations, and ideas about what good looks like. A charter surfaces those differences early, while they are still easy to discuss.

One practitioner, Alex Cowan, teaches the University of Virginia course on Coursera: Managing an Agile Team. argues that the most important choice is the starting point: anchor the charter to a problem instead of a solution, because problems stay durable while solutions change. A team chartered to "reduce failed onboarding sessions" has room to experiment. A team chartered to "build the new onboarding wizard" does not.

Why New Teams Need a Charter

New teams have no shared history. Every working habit, from how quickly people reply to who can approve a change, is a guess until someone says it aloud.

A charter shortens that guessing period. It also gives the team something to point to when a disagreement starts, so the conversation is about the agreement, not about who is right. Teams that are still learning to work together can also use the charter to move through early friction, which connects naturally to  what is a Scrum team in Agile  discussions of self-managing, cross-functional teams.

A useful charter answers five fundamental questions:

1. Why does the team exist? It describes the problem the team is solving and the value it intends to create.
2. What does success look like? It identifies the outcomes, quality expectations, or measures that indicate progress.
3. Who does what? It clarifies accountabilities, responsibilities, and decision-making boundaries.
4. How will the team work together? It establishes team norms, communication practices, and working agreements.
5. How will the team improve? It explains how members will review their agreements and respond to changing circumstances.

For example, suppose you have an Agile team working on an online appointment booking platform. Although its charter could state that the team will help customers to make appointments easier, it will still ensure the booking and payment processes are reliable.

Then the team could get on the same page regarding code reviews, testing standards, communication channels, and what to do about urgent production defects. The agreements provide direction and don't require anticipating all the challenges right away.

Charter vs Working Agreements vs Team Norms

An agile team charter, working agreements, and team norms are intimately related. But they are for slightly different purposes.

The larger context for the team is a charter:

Working Agreements: Working agreements are specific agreements about how members will work together. Team norms are shared expectations for behaviour that guide everyday interactions.

These categories can overlap. A charter may contain a dedicated working agreements section and list the team's most important norms.

The distinction matters less than whether the team understands and uses its agreements.

For example, a charter might establish respectful communication as a value. The associated team norm could be to challenge ideas without attacking individuals. A working agreement might require participants to let others finish speaking during discussions.

Together, these statements turn an abstract value into observable behavior. If you want to explore the practical side of collaboration, the  Team Norms guide  can help teams develop shared expectations.

When to Create an Agile Team Charter

The most useful time to create an agile team charter is when people begin working toward a shared goal. However, teams do not need to wait until a completely new project starts. A charter can also help when responsibilities, priorities, membership, or working conditions change. The goal is to establish clarity at a point when shared expectations can influence how the team works.

At Team Formation

Writing a charter allows team members to discuss expectations before bad habits develop.

A kickoff meeting or dedicated chartering workshop is good because the team can discuss its purpose, working methods, and responsibilities together. You are a new team building a customer self-service portal. Its members can be developers, testers, a UX designer, a Product Owner, and a  Scrum Master.

Everyone knows their professional responsibilities, but they may not agree on how to deal with incomplete requirements, production incidents, or delayed reviews. The team can use the charter to establish agreements such as:

• The Product Owner clarifies priorities and acceptance criteria.
• Developers and testers collaborate throughout the Sprint.
• Team members raise blockers as soon as they identify them.
• The team records important technical decisions in a shared location.
• Completed work meets the agreed Definition of Done.
• The team reviews its working agreements during retrospectives.

These agreements provide a common starting point. They don't solve every conflict, but they provide the team with a common point of reference for dealing with issues.

Develop the first charter preferably before or at the beginning of the team’s first Sprint. But don’t hold up good work because all the details haven’t been worked out. Better to get a lightweight initial charter than wait for a perfect document.

When Membership or Mission Changes

Existing charters may become obsolete as the team or its environment changes. For example, a team that initially owned an internal reporting tool may later own a customer-facing analytics platform. The new product may introduce new security requirements, new stakeholders, and new availability expectations.

The team would need to revisit its mission, success criteria, dependencies, and Definition of Done. A charter review is also useful when:

• A new Product Owner or team member joins.
• The team combines with another group.
• The organization introduces new compliance requirements.
• Work shifts from a single location to a distributed environment.
• Recurring conflicts indicate that existing agreements are unclear.
• A team health check reveals problems with trust, ownership, or communication.
• an agile maturity assessment can add context identifies inconsistent collaboration practices.

For example, if a team health check reveals that team members often wait many days for decisions, the team might need clearer decision-making rules or escalation paths.

The charter should reflect the team's current reality rather than preserve agreements that no longer help. A practical rule is to review it whenever a meaningful change affects how the team works, and to use regular retrospectives to identify smaller improvements.

Key Elements of an Agile Team Charter

Agile team charter elements vary by team, but most charters use the same building blocks. Pick the ones that solve a real problem for your team, and leave out the rest.

Team Purpose and Mission

State why the team exists in one or two sentences, and tie it to a customer or business problem. A strong purpose statement answers three questions: who we serve, what problem we solve, and why it matters.

For example: "We help first-time customers open an account without calling support." Avoid vague statements such as "deliver high-quality software", which could describe any team.

Vision and Success Criteria

The vision describes the change you hope to see in six to twelve months. Success criteria make it measurable. Use outcomes, not output: "70 percent of new customers finish onboarding in one session" says more than "release the onboarding wizard".

Keep the number of criteria small. Three is usually plenty. Remember that success criteria are hypotheses to test, so revisit them as you learn.

Values and Team Norms

Values are the principles that guide decisions, and team norms translate them into everyday behavior. A value like "transparency" becomes a norm such as "we share bad news within a day". Concrete norms are easier to follow and easier to challenge.

For a deeper look at writing norms that stick, see this guide to  team norms. As a rule, five or six norms are enough. Each should describe behavior you could observe.

Roles and Responsibilities

This section covers agile team charter roles and responsibilities. List each member, their role, and what they own. In Scrum, that means the Product Owner, Scrum Master, and Developers, plus any specialists such as a designer or tester.

Cowan notes that this is worth the few minutes it takes, because it helps people from other teams understand who is doing what. Also note who has the final say in each area, so decisions do not stall.

Working Agreements and Ways of Working

Working agreements are the practical rules that keep daily work smooth. They cover meeting schedules, work hours and overlap, code review expectations, how work moves across the board, and how the team handles interruptions.

Be explicit about the practices you use and do not use. Cowan suggests that being explicit about which practices you implement lets you evolve them through experiments. If you do not track burndown, write that down.

Definition of Done and Ready

The Definition of Done describes what ‘finished’ means for a work item. It might include code review, passing automated tests, updated documentation, and acceptance by the Product Owner. A Definition of Ready, if you use one, describes when a story is clear enough to start.

Write these down in the charter, or link to them. Doing so removes a common source of friction between  developers, testers, and product owners.

Communication and Decision-Making

Describe how the team communicates: which channels for which purposes, expected response times, and when to switch from chat to a call. Then describe how it decides. Does the team use consensus, consent, or a named owner for each type of decision?

Teams often skip the second half, then argue about decisions later. A one-line decision rule for each category, such as technical choices or priority changes, prevents most of those arguments.

Stakeholders and Dependencies

List the people and teams who depend on your work or whose work you depend on. Note how often you will engage with each and what they can expect from you.

This section is short, but it prevents surprises. It also reveals hidden dependencies early, when you can still plan around them.

How to Create an Agile Team Charter Step by Step

Wondering how to create an agile team charter without it turning into a long meeting? Keep the process light and collaborative. Four steps cover it.

Step 1: Run a Collaborative Chartering Workshop

An agile team charter workshop gives everyone a voice at the start. Allow 60 to 90 minutes for a team of six to eight and invite the whole team, including the Product Owner.

A simple agenda works:

1. Frame the problem (10 minutes): Share what the team will address and why it matters.
2. Silent brainstorm (10 minutes): Each person writes ideas for purpose, norms, and working agreements on sticky notes.
3. Cluster and discuss (30 minutes): Group the notes and discuss disagreements.
4. Agree and assign (20 minutes): Confirm what goes in the draft, and name who will write it up.

Cowan suggests an alternative that reduces effort: draft something plausible, send it ahead of the session, discuss it with the team, and then treat it as an experiment. That approach works well when time is short.

Step 2: Draft Each Section as a Team

Let the team own the wording. Split into pairs for different sections, then read the drafts aloud and edit together. Use plain language, and write in the first person plural: "we".

Check each line with two questions. Can someone observe whether we do it? Would a new member understand it without extra explanation? If either answer is no, rewrite it.

Step 3: Make It Visible and Living

A charter that lives in a forgotten folder helps nobody. Put it where the team works: pinned in the team channel, linked from the board, or printed beside the team's wall.

Mention it in practice. Bring it up in sprint planning when scope questions surface, nd in retrospectives when norms start to slip. When it informs decisions, it is a living document.

Step 4: Revisit and Update Regularly

Review the charter every three to four sprints, or at the end of a release. Ask what is working, what no longer fits, and what is missing.

Keep a short change log, as Cowan recommends, so you can later see why you changed a practice and how outcomes related to it. Small, frequent edits beat a big rewrite once a year.

Agile Team Charter Example

This agile team charter example shows how the elements fit together. It is hypothetical and written for a six-person  Scrum team  at a mid-size insurer. Use it to see the level of detail to aim for, not as a text to copy.

Team: Onboarding Squad

Purpose: We help first-time customers open an account in one session, without calling support.

Vision and success criteria: A new customer completes onboarding unassisted, in a single sitting, within nine months. We will track the percentage of customers completing in one session, support calls related to onboarding, and customer satisfaction after the first week.

Values: Customer first. Transparency. Learning over blame.

Team norms:

• We critique work, not people.
• We share bad news within one working day.
• We decide in the open, and then we support the decision.
• We ask for help when blocked for more than a day.

Roles:

Working agreements: Two-week sprints. Standup at 10:00, fifteen minutes. First code review within four working hours. Core overlap 11:00 to 15:00. We do not track burndown, and we review flow on the board each week.

Definition of Done: Reviewed, automated tests passing, accessibility checks done, documentation updated and accepted by the  Product Owner.

Decision rules: Technical choices are made by developers with consent.

Changed priorities: Product Owner decides after discussion with team.

Process changes: The whole team decides in retrospective.

Stakeholders: Customer support (monthly sync), compliance (before each release), and the platform team (shared environments).

Review cadence: Every third retrospective.

What the example shows: Each line is short and observable. The roles table is quick to scan, and the norms describe behavior the team can check. The charter fits on two pages, which makes it more likely people will read it.

Agile Team Charter Template

Use this free agile team charter template as a starting point. Copy it into a document or whiteboard, and replace the prompts with your team's own words. Treat the format as flexible: add or remove rows to suit your context.

A Section-by-Section Template

Tips for Keeping It Lightweight

A charter that nobody reads is worse than none. These tips keep it useful:

• Limit it to two pages: If a section grows, link to a separate document.
• Write rules you can observe: "Reply within one working day" beats "communicate well".
• Start small: Cowan advises not to over-invest in perfecting it up front, and to update it diligently as you learn what the team actually does.
• Cut what does not matter: If a section does not change behavior, delete it.
• Use the team's words: Plain language beats corporate phrasing.

Benefits of an Agile Team Charter

A charter does not guarantee a great team, but it removes avoidable friction. The benefits show up mostly in the first months and during times of change.

Alignment, Clarity, and Faster Norming

When everyone has read and agreed to the same purpose, priorities line up faster. People stop guessing about roles and routines, so the team spends less time in confusion.

It also speeds the move from early friction to stable habits, which is often called norming. Teams that document their expectations early tend to reach shared habits sooner than those who let them emerge slowly. Treat that as a reasonable expectation, not a promise, since results depend on how the team uses the document.

Fewer Misunderstandings and Conflicts

Many conflicts come from mismatched expectations, not bad intent. One person expects quick replies, another expects focused hours, and both feel disrespected. A written norm on response times removes the guesswork.

A charter also gives teams a neutral reference. When someone breaks an agreement, the team can say, "We agreed to this," instead of making it personal. That keeps the conversation on behavior and makes repair easier.

The Scrum Master's Role in Chartering

The Scrum Master does not write the charter for the team. Their role is to create the conditions for the team to write it well and keep it relevant. This fits the Scrum Master's broader job of helping the team become more effective.

Facilitating the Workshop

In the workshop, the Scrum Master:

• Sets the purpose and the time limit
• Makes sure quieter members contribute
• Keeps the discussion on observable behavior
• Helps the team resolve disagreements instead of voting too early
• Records decisions and gets the draft written up quickly

They also prepare. A short pre-read on what a charter is, plus a draft of the problem statement, helps the session start with focus.

Keeping the Charter Alive

After the workshop, the Scrum Master helps the team use the document. They bring it into retrospectives, point out where practice has drifted from the agreements, and prompt reviews when the team changes.

They can also pair the charter with lightweight check-ins. A periodic team health check shows how people feel about collaboration, trust, and workload, and the results often suggest which norms to revisit. For a broader view of how the team's practices are developing over time, an  agile maturity assessment  can add context, although a charter alone does not make a team more mature. It is one input among several.

Scrum Masters who want structured practice in facilitating this kind of work can explore  SAFe Scrum Master Certification Training, which covers team coaching and improvement across a Release Train.

Common Mistakes and Best Practices

Agile Team Charter Common Mistakes

Even a well-designed  agile team  charter can become ineffective if the team treats it as a formality. The following mistakes can reduce its value, along with practical ways to avoid them.

Agile Team Charter Best Practices

Besides avoiding these mistakes, there are a few practices that could make the charter more useful.

Begin with the problem, not the template: Determine what the team needs to know before they can finish the sections. A team with chronic handoff delays may require different agreements than a team with stakeholder priority challenges.

Foster authentic engagement: Allow everyone to make a contribution. If power differences inhibit open discussion, use anonymous input or individual brainstorming.

Make agreements work: If a rule cannot be consistently followed, the team will soon lose credibility in it. Take into account operational needs, existing policies, time zones, and working hours.

Link agreements to observable behaviour: We value accountability, and it shows in how members communicate missed commitments, ask for help, and finish actions.

Test and improve agreements: When the success of new working practices is unknown, try them as experiments. Review results and modify as experience dictates.

Respect the team's independence: The charter should provide reasonable limits, not require all action. Teams need space to make decisions and adjust their approach as they learn.

Accurately evaluate improvement: Use relevant evidence (e.g., recurring blockers, delivery delays, team feedback, quality issues) to understand if it’s working. And don't assume that just because a charter is completed, performance will be better.

It is not the charter with the most sections that is the best. It is the one that the team understands, agrees to, and uses to guide its work.

Conclusion

An agile team charter gives a team a shared answer to a simple question: how do we want to work together? Its value comes less from the document than from the conversation that produces it, and from the habit of revisiting it.

Start small. Run a short workshop, anchor to a problem, write a handful of norms people can observe and agree on how you will decide. Then put the charter where the team can see it, and review it every few sprints.

If your team has no charter yet, copy the template above and try the workshop in your next sprint. One honest hour of discussion will likely save many hours of confusion later.