Team Charter Template: Make Working Agreements You Can Use
Download a team charter template with a complete example, practical working agreements, a short workshop agenda, and a process for revising the rules.
A team charter records why a team exists, what it is responsible for, how decisions are made, and how members agree to work together. Create it with the people who must use it. A charter becomes useful when it resolves a real uncertainty, such as who can change priorities or what happens when commitments conflict.
“Respect each other” is a good intention. “Raise a delivery risk before the handoff, and agree who informs the requester” is an agreement someone can follow.
What should the charter include?
Include purpose, boundaries, responsibilities, decision rights, working agreements, and a review process. The document should help a member understand what they can decide, what they owe other people, and where to go when the agreement stops fitting the work.
Download the editable team charter. The plain text document includes prompts, a completed example, and a discussion agenda. Copy it into the shared space your team already uses.
| Section | A useful question |
|---|---|
| Purpose | What result does this team exist to support? |
| Boundaries | What work belongs here, and what needs another owner? |
| Responsibilities | Who maintains each important part of the work? |
| Decision rights | Who can decide, who contributes, and who needs to know? |
| Working agreements | What observable behavior can members rely on? |
| Review process | When and how can the team change the agreement? |
The Iowa Department of Management describes a charter as a collectively developed document clarifying purpose, outcomes, goals, and constraints. The collective part matters: a manager's announcement does not demonstrate that members understand or can meet the expectations.
Keep this document distinct from a project brief. A brief defines a particular deliverable. A team charter defines how the group will operate across that work, potentially across many projects.
What does a useful example look like?
A useful charter translates broad values into actions and makes authority explicit. The following example is fictional and designed for a three-person operations group maintaining a shared support guide; it is not a report of a real team's performance.
Purpose: keep the guide accurate and usable so support colleagues can find the currently approved process.
Boundaries: the group maintains explanations and links. It does not independently change policy, promise product changes, or resolve individual personnel matters.
Responsibilities: Lee maintains the work queue, Robin coordinates drafting, and Sam checks that approved changes are published and announced. Each named owner confirms coverage before an absence.
Decision rights: the group can correct formatting and broken links. Policy wording requires approval from the policy owner. Lee coordinates priority conflicts but escalates a conflict between departmental commitments to the sponsor.
Work intake: new requests enter the shared queue. A request is not a commitment until the group confirms its scope, owner, and place among existing work.
Response agreement: members acknowledge a direct work request within one business day when working. An acknowledgment may be “I have seen this and will confirm timing tomorrow”; it does not imply completion. This is a negotiated example, not a universal service standard.
Risk agreement: a member who sees a commitment at risk identifies the blocked step and proposed next action. The group agrees who informs the requester before changing the delivery expectation.
Review: revisit the charter after the next delivery cycle or when membership, responsibilities, or recurring friction changes the way the group works.
Responsiveness does not require continuous availability, and membership does not grant unlimited authority.
Atlassian's Working Agreements play asks teams to establish mutual expectations about how they work and communicate. Its practical value is the conversation about different needs, not the act of filling every box in a template.
How do you create it together?
Collect individual perspectives before negotiating shared rules. If the first draft comes entirely from the loudest or most senior member, the document may record that person's preferences while hiding everyone else's constraints.
Ask each member to prepare brief answers to three questions:
- What do you need from others to do reliable work?
- What can others reasonably expect from you?
- Where has an unclear expectation caused friction?
Discuss specific situations rather than assigning personality labels. “I did not know that the deadline had changed” can lead to a useful notification rule. “People here are bad communicators” gives the group little to act on.
Here is an original 40-minute agenda for a small team. Extend it if the discussion needs more time; the schedule is a facilitation suggestion, not a research result.
| Minutes | Discussion | Required result |
|---|---|---|
| 0–8 | Purpose and boundaries | Shared reason for the team |
| 8–18 | Responsibilities and authority | Named decisions and owners |
| 18–32 | Recurring friction and proposed rules | Observable working agreements |
| 32–40 | Test scenarios and review timing | Corrections and next check |
The blocks total 40 minutes. Test the draft with a realistic situation: a late request arrives while an existing commitment is already at risk. Ask each person what the charter says they should do. Different answers reveal language that still needs work.
Iowa's guidance includes using a charter to establish a team's focus. Apply that focus by removing rules that do not help the group work or make a decision. A long list of aspirational values can obscure the few agreements people actually need.
For a new project, bring the relevant charter decisions into the kickoff conversation. Avoid reopening settled rules unless the project's conditions require a change.
How do you handle disagreement?
Agree on the decision process before a difficult choice appears. A charter should explain who decides and how concerns are heard; it should not imply that every disagreement requires unanimous enthusiasm.
Separate three situations:
- A preference: two people favor different tools, but either can support the work.
- A practical constraint: a proposed response window conflicts with a member's working hours.
- An authority boundary: the team is being asked to make a decision that belongs elsewhere.
The designated owner can resolve a preference. A practical constraint needs adaptation; an authority boundary needs the correct decision maker.
Ask members to describe the consequence of their concern. “I cannot reliably review requests during that window” is information the group can use. Do not treat it as resistance that a signature will solve.
The Working Agreements play encourages surfacing individual working needs. Keep the discussion concrete and avoid requiring disclosure of private reasons when the team only needs to know the operational constraint.
If an extra request exceeds agreed capacity, use a clear workplace boundary script. A charter can support the conversation, but it cannot decide which two conflicting commitments your manager values more.
When should the charter change?
Review it when the team changes or when repeated experience shows that an agreement is unclear or unworkable. Do not preserve a failing rule merely because everyone accepted it under different conditions.
Use one recent example at the review. What happened? Which agreement applied? Did members interpret it the same way? Could they follow it with the resources and authority available?
If the acknowledgment rule repeatedly fails because requests arrive in several private channels, changing the deadline may not solve the problem. The better correction may be one visible intake location and a named person checking it.
Record the revised wording, reason, and effective date. Tell affected collaborators; changing a private copy does not update shared expectations.
Use a one-on-one meeting for individual support needs that should not become a group discussion. Use the charter for shared operating rules.
Do Only 3 Things a Day helps translate clear priorities into personal execution. The team agreement makes room for focused work; each member still needs a realistic daily plan within that room.
Frequently asked questions
Is a team charter the same as a project charter?
No. A team charter focuses on the group's purpose and working agreements. A project charter commonly authorizes a specific project and its boundaries. Follow your organization's terminology and approval requirements.
Does everyone need to sign it?
A signature can record acknowledgment, but it does not prove understanding or feasibility. Discuss the agreement and test examples first. Use formal signatures only when your organization's process calls for them.
What if someone breaks an agreement?
Clarify what happened before assigning intent. Check whether the rule was understood and possible to follow. Address repeated behavior through the appropriate management process rather than treating the charter as a substitute for it.
Can a two-person team use this?
Yes. Keep the document proportionate. Purpose, responsibilities, decision rights, and a few practical agreements can prevent confusion even when only two people share the work.