# Team Charter: [Team name]

> A team charter is the team's own agreement on why it exists, what it
> is responsible for, how its members work together, how decisions are
> made and how disagreement is handled. It is written by the team, for
> the team, usually in a facilitated session at the start of a project
> or when membership changes, and it is revisited regularly. It
> complements the project charter, which authorises the project from
> above. Based on common team practice and on published research on team
> development and psychological safety. Replace every `[bracketed]` value
> and every row marked *Example*.

<!--
Guidance: How to use this template
- Write it together in one workshop of two to three hours. A charter
  written by the manager and sent round is a memo, not an agreement.
- Keep each norm short and observable: "cameras optional, responses to
  direct messages within 4 working hours" is better than "communicate
  well".
- Agree the decision rules (section 5) before the first hard decision,
  not during it.
- Review it at retrospectives and whenever someone joins or leaves. New
  members should be able to suggest changes, not just sign.
- Expect the agreements to be tested. Teams often move through forming,
  storming, norming and performing (Tuckman, 1965); friction in the early
  weeks is normal and is the moment to use section 7, not abandon it.
- Common pitfall: a charter that is never looked at again. Link it from
  the team's main workspace and check one section at each retrospective.
-->

## Document control

<!-- Guidance: Treat the charter as a living document. Record each review even if nothing changed. -->

| Field | Value |
|---|---|
| Document ID | [TC-TEAM-NN] |
| Team | [Team name] |
| Project or product | [Project or product name] |
| Version | [1.0] |
| Status | [Draft / Agreed / Under review] |
| Facilitator | [@facilitator] |
| Agreed on | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

Every member records agreement. Sponsor or manager acknowledgement is
optional and confirms support for the team's working agreements.

| Name | Role | Agreed | Date |
|---|---|---|---|
| [@member] | [Role] | [Yes] | YYYY-MM-DD |
| [@manager] | [Sponsor or line manager, acknowledgement] | [Yes] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [Team] | First agreed version |
| 1.1 *(Example)* | YYYY-MM-DD | [Team] | Core hours changed after a new member joined from another time zone |

The worked example is the **Portal team** on the fictional **Brackwell
Vale Housing Trust** Tenant Services Portal project: seven people across
the trust and two suppliers, working hybrid across two time zones.

## 1. Purpose

<!-- Guidance: One or two sentences: why this team exists and who it serves. Link to the project charter or product vision instead of repeating them. -->

[Purpose statement]

*Example:* We give Brackwell Vale tenants a portal they can use to report
repairs and pay rent without calling us, and we hand the contact centre
a service it trusts.

## 2. Goals and measures of success

<!-- Guidance: Three to five goals the team controls, with how it will know it succeeded. Use the project's objectives where they exist. -->

| ID | Goal | Measure | Target |
|---|---|---|---|
| TG-1 | [Goal] | [Measure] | [Target] |
| TG-1 *(Example)* | Ship portal releases tenants can use | Releases passing accessibility review first time | 9 of 10 |
| TG-2 *(Example)* | Keep a sustainable pace | Overtime hours per person per month | Under 8 |
| TG-3 *(Example)* | Learn as a team | Retrospective actions completed by next retrospective | 80% or more |

## 3. Scope and boundaries

<!-- Guidance: What the team owns, what it does not, and where its authority ends. Clear boundaries prevent most cross-team friction. -->

| The team owns | The team does not own | Escalate to |
|---|---|---|
| [Area] | [Area] | [@name] |
| *Example:* Portal configuration and front-end changes | Legacy housing system | [@project-manager] |
| *Example:* Release scheduling within the stage plan | Budget and contract changes | [@project-manager] |

## 4. Roles and responsibilities

<!-- Guidance: Who does what, including rotating duties. Use a RACI (business/raci) for detail. Name a back-up for each critical role. -->

| Name | Role | Main responsibilities | Back-up |
|---|---|---|---|
| [@name] | [Role] | [Responsibilities] | [@name] |
| [@lead] *(Example)* | Team lead | Plans work with the team, removes blockers, reports to the project manager | [@dev-1] |
| [@po] *(Example)* | Product owner | Orders the backlog, accepts stories | [@senior-user-delegate] |
| [@ux] *(Example)* | Designer | Design and accessibility | [@dev-2] |

Rotating duties: [meeting facilitator, release captain, note taker, rotation period].

## 5. Decision rules

<!-- Guidance: Agree which decisions use which rule and what happens when the team is stuck. Typical rules: the person responsible decides after consulting; consent (no reasoned objection); majority vote; unanimity for a few critical choices. -->

| Decision type | Rule | Who decides if stuck | Time limit |
|---|---|---|---|
| [Type] | [Rule] | [@name] | [Time] |
| *Example:* Technical design inside the portal | Responsible developer decides after consulting at least one peer | Team lead | 2 working days |
| *Example:* Changes to these working agreements | Consent: adopted unless someone states a reasoned objection | Facilitator runs a second round | Next retrospective |
| *Example:* Backlog order | Product owner decides | Senior user | Sprint planning |

Record significant decisions in the [Decision log](../business/decision-log.md).

## 6. Working agreements

<!-- Guidance: Observable norms the team chose. Cover time, communication, meetings, quality and well-being. -->

| Area | Agreement |
|---|---|
| Core hours | [Hours and time zones] |
| Communication channels | [Which channel for what, expected response times] |
| Meetings | [Cadence, agenda, cameras, notes] |
| Quality | [Definition of done, review rules] |
| Availability and leave | [How to signal absence] |
| Focus time | [Protected time] |
| *Example:* Core hours | 10:00 to 15:00 UK time, Monday to Thursday |
| *Example:* Channels | Chat for quick questions (reply within 4 working hours), tickets for work, email for external parties |
| *Example:* Meetings | Daily stand-up 15 minutes, no meetings on Friday mornings |
| *Example:* Quality | A story is done only when it meets the team's definition of done |

## 7. Conflict and feedback

<!-- Guidance: How disagreements are raised and resolved, and how feedback is given. Make it safe to disagree and to admit mistakes: research on psychological safety links it to team learning. -->

- Raise disagreement with the person first, in private, within [N] working days.
- If unresolved, bring it to [the team lead / a retrospective / a neutral facilitator].
- Feedback is specific, about behaviour and its effect, and given in time to act on.
- *Example:* "Disagree and commit": once a decision is made under the
  agreed rule, everyone supports it and the dissent is recorded.

## 8. Team health check

<!-- Guidance: A short recurring check of how the team works. Score 1 to 5 at each retrospective and discuss the lowest. -->

| Area | Score (1 to 5) | Trend | Action |
|---|---|---|---|
| [Area] | [Score] | [Up / Same / Down] | [Action] |
| *Example:* We can raise problems without fear | 4 | Same | None |
| *Example:* We protect focus time | 2 | Down | Move status updates to written check-ins |

## 9. Related templates

<!-- Guidance: Link the documents the charter relies on. -->

- [Project charter](./project-charter.md), which authorises the project
- [RACI matrix](../business/raci.md)
- [Sprint retrospective](../product/sprint-retro.md), where the charter is reviewed
- [Communication plan](./communication-plan.md)
- [Definition of done](../product/definition-of-done.md)

## Glossary

- **Working agreement:** a norm the team chose for how it works together.
- **Consent decision:** a proposal is adopted unless a member gives a reasoned objection.
- **Psychological safety:** a shared belief that the team is safe for interpersonal risk taking, such as asking questions or admitting mistakes.
- **Retrospective:** a regular team meeting to inspect and improve how the team works.

## Standard and licence note

Based on common team practice. The forming, storming, norming and
performing sequence comes from B. W. Tuckman, "Developmental sequence in
small groups", *Psychological Bulletin* 63(6), 384 to 399 (1965),
https://doi.org/10.1037/h0022100. Psychological safety is described in
A. Edmondson, "Psychological Safety and Learning Behavior in Work
Teams", *Administrative Science Quarterly* 44(2), 350 to 383 (1999),
https://doi.org/10.2307/2666999. The sources are cited only; the
sections, wording and fictional example are original. Template licence:
MIT.