Team Charters: How to Create One that Rocks

Team charters answer one big question. Why do we exist? It sounds like the kind of question that belongs in a philosophy classroom or a late-night dorm room. But teams should answer this question to improve their work. One way they can do it is with team charters.

When teams clarify their existence and document the answers, they’re creating a team charter.

It’s like a job description or constitution for a team.

In this article you’re going to learn how to create team charters and what to include in one!

A team charter is a document that states why a team exists and what’s required to fulfil their purpose. It explains who the team members are, their roles, goals, and what resources and constraints they’ll work with.

When’s the best time to create a team charter? When you start a new team, of course. But you can also draft one up when you onboard a new team member, need buy-in from stakeholders, or want to get an underperforming team back on track.

🎓️ The difference between team and project charters.

A team charter focuses on one team, its members, and how they’ll collaborate – often on many projects. A project charter lists requirements for one project, which may involve members and resources from across one or more organizations.

Below you’ll find all the elements you can use to build a team charter. First we’ll cover these before getting into the practical “how to” so you know what to include.

✨ To skip directly to the walkthrough, click here ✨

Don’t feel obligated to use each one of these building blocks. Which of the ingredients you add depends on your team’s goals, the complexity of your mission, and how long your team will work together. The document only needs whatever information will align and motivate the team and other stakeholders. Get rid of any fluff that doesn’t.

This section is like a preface to a book. It sets the stage for the rest of the charter by explaining the circumstances that led to its creation.

Often the intro starts from a zoomed-out perspective, looking at a broad challenge the business faces. Then it zooms in on how a dedicated team might address this problem.

Essentially, it’s a build-up to the next and most critical part of a team charter: its mission.

🎓️ You can also regard the intro as a mission brief – input for creating the mission statement, the next step.

Example

For several years now, our organization has struggled to reap the full benefits of agile. For this reason, we want to establish a permanent team of dedicated agile coaches to lead and complete our agile transformation.

The mission states why a team exists. For some groups, the reason is straightforward, like completing a specific project. For others the mission can be broader and aspirational.

Consider these questions to arrive at your mission statement:

Example:

Short term project

You’re creating a project team to deliver a new feature for your app. The group will work together for a few months at most. Their mission statement is straightforward. They might arrive at a mission statement that looks like this after a short session:

Our mission is to deliver feature X to solve customer problem Y and increase business metric Z by 10%.

This statement doesn’t take long to create and gives enough team direction for a group that’s together temporarily. A short-term team charter may sound similar to a sprint goal.

Long term project

On the other end of the spectrum are groups that will exist and work together indefinitely. In such cases, you spend much more time on the earlier-listed questions and answer them in more detail to get to the team’s purpose. Such a group might arrive at a statement like:

The marketing team exists to represent the customer’s voice inside the company and the company’s voice outside of it. We’re the fiercest evangelists of the organization’s mission and enable other teams – especially Sales and Product – to reach their objectives.

This section establishes what the team needs to achieve in concrete terms. Whatever you put here should help the team measure their progress and success.

While the mission statement is sometimes lofty, deliverables and results are more down to earth.

If your team works together for a short timeframe, say one project, then the most important goal is the desired result that marks the end of the project and team.

If your group exists indefinitely, you’ll likely measure progress and results with specific metrics, often expressed as KPIs or OKRs. Such numbers go into this section, along with explanations of why they matter and with benchmarks you want to measure yourself against.

Other information you can include here are deliverables the team is responsible for, like documents, reports, or process descriptions.

Example

Our team’s main objective is to improve user retention for our mobile app. The ideal customer uses our product at least once per week, so our North Star is the weekly retention metric (i.e., do users return at least once per week).

We’ll complement our North Star with quarterly OKRs, which we determine based on companywide objectives and our own observations throughout each quarter.

Our essential deliverables are:

In this section, your team defines what’s on and off-limits.

Ask yourselves questions like:

As you answer such questions, especially at larger organizations, it’s normal to run into grey areas between your responsibilities and those of other departments.

Depending on the amount of overlap you may need to decide if it’s a critical issue to resolve now or something to note for further clarification later.

This section is also ideal for stating how long the team will work together if the collaboration has an end date.

Example

The IT team’s primary responsibilities are:

Decision-making authority:The team can independently decide within these areas of responsibility if the expected consequences and risks don’t affect others. We can make spending decisions within budget and not greater than $20,000.

The team holds a veto right on IT-related purchases such as equipment and software selection.

The who’s who of your team charter lives here, except you might express “who” as a role (e.g. “Senior Software Developer”) instead of a specific name. This gives your team charter longevity as individual employees may come and go.

When you start with names, you’ll likely fit roles to those people. When you start with roles, you can tailor them to the team’s mission, goals, and scope.

Then you look at the people you have and whether they fit those positions. If not, you’ll need to look elsewhere to put together the right high-performing team for the job.

No matter how you approach this, always tie roles back to the team’s mission. Doing so ensures you have the people you need to hit the objective and creates individual alignment and motivation.

Each member of the team will then understand how their role relates to the overall mission.

Once you have defined all the positions you need, list explicit responsibilities for each one. The level of detail here depends on the scope and duration of the team’s existence. Note that people can hold more than one role on a team.

Teams with a broad scope and long life benefit from detail and clarity in this section. A specific understanding of each role creates cohesion and prevents competition, confusion, and mistakes once you work together. For the same reason, it can prove helpful to list relationships team members will have outside the team, like with stakeholders and vendors.

Example

Our Product team is cross-functional, so we can achieve our mission of delivering a world-class app through updates released autonomously. These requirements mean our team needs four Software Developers, a Growth Marketer, and a UX designer.

The UX Designer needs to have experience doing user research and design for mobile apps. This role handles:

Here we get to the how of the team’s daily work. Anything related to the logistics of working together as a team can go in this section. A few common questions people often address are:

Team meetings

First, define which meetings you’ll regularly have. (Here are some tips for when to call one). Then address logistics about meeting agendas, required versus optional attendees, note-taking, meeting tools, and (virtual) locations. You might also establish do’s and don’ts for meetings, like no phones and laptops allowed, and drinks are ok but no food.

Decisions

Define how to make decisions within the team. Do you follow a specific process? Perhaps you document and analyze the results of your choices in a decision journal? Who gets to make which decisions within the team?

Communication

Consider which tools you’ll use for different types of communication. What goes in an email? What’s better to discuss on Slack or Teams? Can you discuss some meetings or topics async?

Also, consider how you’ll track progress on your goals within the team. Who notifies whom about which data? Do you need to create any regular reports?

You may also want to decide when not to communicate with each other, so everyone has time for daily deep work.

Example

We’ll follow the standard Scrum events based on two-week Sprints. All our meetings are run using Parabol. Drinks are ok, but no food, please.

Every meeting needs a purpose and agenda available for all attendees 24 hours in advance. Meetings that don’t meet this rule get canceled, unless they are retrospectives. We observe the Law of Two Feet and Wednesdays are meeting-free, so we have time for focused work.

Our default for communication is async on Slack. Only external communications or those with formal, legal content go on email. We schedule all our messages to send in the morning if it’s after 19:00 in the recipient’s time-zone to respect each other’s work-life balance.

There’s no right or wrong way to make team charters. You’re free to add – and even make up – sections if you believe they’ll contribute to the team’s success. Here are some other ideas to include in your team charter:

Now that you understand all the elements of team charters, work with your team to put one together using the process below.

You can also check out our purpose built team charter meeting template.

These steps unfold over one or more meetings with the entire team, not just a few managers. The charter’s purpose is to get everyone aligned and on board, and you won’t achieve that result with a top-down mandated document.

How many meetings you’ll need depends on the size of your team, its scope, and its lifespan – larger and longer means more brainstorming sessions.

Clarify with your team what purpose the team charter will serve. This information will form or inform the intro and context for your team charter.

Start brainstorming and defining your team’s mission and objectives. Usually, you do this first with the team members and only later involve stakeholders for feedback and, if necessary, approval. If you’re a Scrum self-managing team, you don’t need anyone’s approval! You can do this brainstorming in Parabol or another structured communication tool.

We recommend trying the following template to guide your discussion:

Include other elements in your team charter by discussing which aspects of your work need clarity to achieve your mission and goals. You work through those with your team in a similar way as the previous step. You only gather input from outside stakeholders where necessary.

Determine which milestones and actions from your charter should go on your team’s calendar and to-do list. Regularly reflecting on your team charter when devising sprint goals or during Retrospective meetings can also be helpful. You can see whether you’re working together in the way you intended and moving closer to fulfilling your mission.

Remember your team charter is a living document that can be amended at any time with the team’s consent. If it’s not serving you well, inspect and adapt it.

Get team members and stakeholders to commit to the charter after gathering their final questions and feedback. You can do this informally or ask people to put their signatures on a printed copy if you want to be really formal about it!

Ask one or more team members to create a finalized and centralized document everyone can access. Then create variations of your team charter, like posters, illustrations, and highlights that you can put on walls, task boards, or even t-shirts.

Your document may live as a physical document or in a centralised wiki, such as Notion.

As you hold one or more meetings to walk through the steps above, you might run into awkward silences, standstills, and even conflicts. Here are a few tips to get through those:

🎓️ Looking for more tips on meeting facilitation and improving meetings? Check out Improve any Meeting with Agile Thinking.

Team charters don’t have to be dry documents full of business jargon; they can be works of art. The format and style you choose depend on your company culture, team members’ preferences, and how much time you’re willing to invest.

If you go wild on yours, we’d love to see it. Please share it with us on Twitter.