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
Time off calendar
Project swimlanes - Ready for development, In progress, In Review, In QA, Done
Sad/Mad/Glad or Kudos/What Went Well/What could do better/Action Items
Pull Request Template
How we do Pull Request reviews
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
Request for Comments (RFC)
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
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