Team Charter and Norms

A Team Charter in the context of a software engineering team is a team document that lists their goals, objectives, scope of work, and rules of engagement. This is a working agreement between all members of the team on how the team collaborates and communicates, and how they hold each other accountable while working towards common goals.

Here are some areas I like to cover in a team’s Team Charter. This can be at the team level or the organization level. 

  • Goals: This is a one-line sentence that explains the goal(s) of this team. 

  • Objectives: This section links to the team or organization's objectives, key performance indicators (KPI) or Objectives and Key Results (OKR) which can be quarterly, semi-annual or annual.

  • Organization Chart and Team Structure: This helps people know where they are in the organization and what teams and people they interact with regularly.

  • Helpful Resources: This links to the team’s Request For Comment or Technical Design Documents, Slack channels, meeting notes and self-service meeting invites.

  • Team Norms: This documents how the team works together, what processes they use for meetings, giving feedback and triage.

  • Dashboards: This shows metrics that the team tracks on a regular basis.

  • Time off calendar: This links to the team’s time off calendar or shows an embedded team calendar.

The Team Charter essentially is the source of truth for anyone onboarding on the team and is a living document for recording how the team works together. 

✍🏽 Documenting a Team Charter

Most project management tools such as Confluence offer templates for a Team Charter like this Homepage. When I join a new team, I usually start at their Home page or onboarding docs and update it as I go. Here’s how I go about it if the team does not have a Home page or Team Charter:

  • Start with the goal(s) of the team. 

  • Use a pre-existing template for a Team Charter and fill out everything I learn as I go. Add new sections as needed. 

  • If the team has never run a Team Norms setting meeting and there is a need for one, then facilitate the meeting. This is usually recognizable if features are not delivered on time or there is no clear ownership or accountability on different scopes of work.

  • Send a new collaborative Team Norms document out beforehand with clear instructions to the team on how and when they need to fill this document by. 

  • Meet once or twice to go through the working document above and record decisions for every single section. 

  • Update the relevant sections in the Team Charter document above.

  • Encourage everyone on the team including new hires to update the Team Charter as needed and to drop a note in Slack about changes made. 

🗣️ Team Norms - Topics of Discussion

Any of the following people in the role of Engineering Manager, Program Manager, Scrum Facilitator or Team Lead can facilitate a Team Norms setting meeting. This meeting can take place over 1 to 2 hour-long sessions. High-level outcomes are recorded in the Team Charter. It also makes sense to meet every 6 months or so when the team processes start breaking down. Here are some discussion topics for the team norm settings meeting:


  • Preferred daily stand-up time and length keeping time zones in mind

  • Preferred stand-up content - yesterday, today, blockers

  • Preferred stand-up days 

  • Preference for Slack stand-up updates


  • Bug, Sub-task, Task, Story, Epic, Epic of Epics

  • Ownership of tickets - Product, Engineering, Program Managers

Backlog Grooming / Refinement

  • Definition of Done for different ticket types

  • Ticket/Issue template

  • Story pointing 

  • Acceptance criteria

  • Creating tickets

Sprint Planning

  • Capacity Planning

  • Time off calendar

  • Project swimlanes - Ready for development, In progress, In Review, In QA, Done

  • Acceptance Criteria

Sprint Retrospective

  • Tools used

  • Sad/Mad/Glad or Kudos/What Went Well/What could do better/Action Items

  • Action items

Pull Requests 

  • Pull Request Template

  • Branch names

  • Branching norms 

  • How we do Pull Request reviews

Meeting times

  • How often to meet

  • When to meet

  • When to use Slack vs meetings

  • Creating “meeting” and “making” blocks of time on calendar

Paid Time Off / Vacation 

  • Where to update - Slack, Time off calendar, Email

  • Coverage Plan documents for longer time off


  • Triage Runbooks

  • On-call rotation

Request for Comments (RFC)

  • RFC template

  • Getting started with an RFC


  • How we give feedback individually

  • Preference for private or public feedback

  • Preference for Slack or video call for feedback


  • Agree on technical and behavioral questions 

  • Rubrics

  • Feedback


  • Involve Product Owner/Designer in Team Norms settings or share document

✅ Measuring success

It can be hard to quantify why teams should write about how they work together but I find this to be a good exercise that helps teams and their leaders keep their eye on the following:

  • Ease of onboarding new members on the team

  • Noting down team process changes and relevant action items from retrospectives in the team charter

  • Ease of working together with each other once norms are established

  • Delivering high-quality projects on time

Emojis from


Popular posts from this blog

Recap of Android Summit 2017

Team Charter and Norms: Working together

Chicago Roboto 2018 Recap + First Keynote!