Markdown Editor

Team Charter Template

Team working agreement: purpose, goals, boundaries, roles and back-ups, decision rules, working agreements, conflict and feedback, team health check

プロジェクト管理標準Common practice; Tuckman (1965), Edmondson (1999)teamcharter

使い方: Use it when a team forms or its membership changes, written together in one workshop. Fill the decision rules and working agreements first, in observable terms. The main pitfall is a charter written by the manager, or one never reviewed after the kick-off.

プレビュー

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.

Document control

FieldValue
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 onYYYY-MM-DD
Next reviewYYYY-MM-DD
Classification[Internal]

Approvals

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

NameRoleAgreedDate
[@member][Role][Yes]YYYY-MM-DD
[@manager][Sponsor or line manager, acknowledgement][Yes]YYYY-MM-DD

Revision history

VersionDateAuthorChange
1.0YYYY-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

[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

IDGoalMeasureTarget
TG-1[Goal][Measure][Target]
TG-1 (Example)Ship portal releases tenants can useReleases passing accessibility review first time9 of 10
TG-2 (Example)Keep a sustainable paceOvertime hours per person per monthUnder 8
TG-3 (Example)Learn as a teamRetrospective actions completed by next retrospective80% or more

3. Scope and boundaries

The team ownsThe team does not ownEscalate to
[Area][Area][@name]
Example: Portal configuration and front-end changesLegacy housing system[@project-manager]
Example: Release scheduling within the stage planBudget and contract changes[@project-manager]

4. Roles and responsibilities

NameRoleMain responsibilitiesBack-up
[@name][Role][Responsibilities][@name]
[@lead] (Example)Team leadPlans work with the team, removes blockers, reports to the project manager[@dev-1]
[@po] (Example)Product ownerOrders the backlog, accepts stories[@senior-user-delegate]
[@ux] (Example)DesignerDesign and accessibility[@dev-2]

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

5. Decision rules

Decision typeRuleWho decides if stuckTime limit
[Type][Rule][@name][Time]
Example: Technical design inside the portalResponsible developer decides after consulting at least one peerTeam lead2 working days
Example: Changes to these working agreementsConsent: adopted unless someone states a reasoned objectionFacilitator runs a second roundNext retrospective
Example: Backlog orderProduct owner decidesSenior userSprint planning

Record significant decisions in the Decision log.

6. Working agreements

AreaAgreement
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 hours10:00 to 15:00 UK time, Monday to Thursday
Example: ChannelsChat for quick questions (reply within 4 working hours), tickets for work, email for external parties
Example: MeetingsDaily stand-up 15 minutes, no meetings on Friday mornings
Example: QualityA story is done only when it meets the team's definition of done

7. Conflict and feedback

  • 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

AreaScore (1 to 5)TrendAction
[Area][Score][Up / Same / Down][Action]
Example: We can raise problems without fear4SameNone
Example: We protect focus time2DownMove status updates to written check-ins

9. Related templates

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.

関連テンプレート