Team working agreements: how to create one (+ template)

A team working agreement is a short, co-created set of rules for how your team works together: how you communicate, run meetings, make decisions, and give feedback. It is not a poster of values, and it is not the same as a team charter. It is the handful of concrete, agreed behaviors you can point to when something slips. This chapter covers what a working agreement is, how to facilitate one in a single session, examples you can copy and adapt, and how to keep it alive in your retrospectives.

Here is the uncomfortable part. Your team already has norms. Someone always replies within minutes; someone else goes dark for a day. One person’s ideas get built on while another’s get talked over. Those patterns are your norms, and they formed whether you chose them or not. Working agreements are the version you pick on purpose instead of the version you inherit from whoever talks loudest.

Values, norms, working agreements, and charters: the difference

These words get thrown around as if they mean the same thing, and they don’t. Esther Derby, who co-wrote the book on agile retrospectives, draws the cleanest line between them, and it is worth getting right before you run a session.

Term	What it is
Values	What matters to the team, usually nouns like Respect or Courage. They may guide behavior, but on their own they are not actionable.
Norms	The informal, often unspoken standards that emerge from how the group actually behaves. They form whether you shape them or not.
Working agreements	Norms made deliberate. Protocols the team develops, agrees to, and writes down. The layer you can act on.
Ground rules	Expected behavior for a specific time and place, such as a retro or a planning session. Narrower than a team-level agreement.
Team charter	The broader kickoff document: purpose, goals, roles, and how you decide, with the working agreements sitting inside it.

Derby’s point, in her breakdown of the terms, is that norms are not optional: a group produces them by existing. The only choice is whether you let them congeal by accident or shape them on purpose, and shaping them on purpose is what a working agreement is.

A charter answers why we exist and how we decide, and you tend to set it once at kickoff. Working agreements answer how we behave day to day, and you revisit them constantly. Values without agreements are a poster on the wall. Norms without agreements are whatever happened to settle in during month one. The agreements are the only layer you can point at when something goes wrong. Atlassian keeps the two artifacts separate for the same reason, pairing a team charter with a lighter, more frequently revisited working agreements play.

Why working agreements are worth the hour

Google’s re:Work team studied what its strongest teams had in common in Project Aristotle. Two of the factors it surfaced are the ones working agreements speak to directly: structure and clarity, meaning people understand what is expected and how the work gets done, and psychological safety, meaning people feel able to speak up. Aristotle is correlational, so read the full re:Work guide as a description of what effective teams share, not a recipe that produces one.

Clear agreements do two things at once. They make expectations visible, so nobody has to guess whether interrupting is fine or whether a message sent at 9pm needs an answer tonight. And they give the team something to point at when a line gets crossed, which is what makes it safe to raise the problem at all. Atlassian’s Teamwork Lab reports that teams with explicit agreements run fewer and more purposeful meetings and hit fewer misunderstandings.

The safety half of that gets its own chapter in building trust and psychological safety; agreements also sit inside the bigger picture of what shapes team dynamics.

How to create team working agreements: a 10-step session

You can write a first set in a single 60-to-90-minute session. The order below is the spine; the point of every step is to end up with agreements the team owns rather than rules the facilitator imposed.

1. Book 60 to 90 minutes with the whole team present. Attendance is buy-in. An agreement the team did not help write is just a policy, and policies get ignored.
2. Set the stage. Say why you are doing this, show two or three example agreements so people know the format, and open with a light check-in question to get everyone’s voice into the room early. You can run that opener live with something like icebreaker questions.
3. Gather the inputs first. Ask each person to share their location, timezone, working hours, and how they like to receive feedback. As facilitator, pre-draft the channel list and an escalation path so the session refines a starting point instead of a blank page. To surface preferences fast, some teams map them on a live team spectrum: where does each person fall between “reply fast” and “protect focus time”?
4. Brainstorm silently, then cluster. Everyone writes proposed agreements on their own before anyone speaks, which stops the loudest voice from setting the agenda. Group the cards across the situations below: communication, meetings, decisions, remote and async work, response times, and conflict.
5. Rewrite every vague line into a behavior you could film. “Be respectful” is a value, not an agreement. “We don’t interrupt, and we argue with the idea rather than the person” is something you can watch happen or fail to happen.
6. Decide sync versus async on purpose, and name who decides. For each topic, agree whether it needs a live conversation or a written thread, and name the person who breaks a tie when consensus stalls.
7. Confirm commitment out loud. Use a Fist of Five or a Roman vote (thumb up or down) on each agreement. Silence is not a yes. If someone signals a two, you talk until it becomes a real agreement or you drop it.
8. Cap the list at five to ten. A long list is an ignored list. Thirty rules is the same as zero. Pick the few that fix your team’s real friction and add more only when a genuine problem shows up.
9. Post them where the work happens. Pin them in the team channel, the wiki, or the top of the board, wherever people already look. It is a living document, not a slide deck nobody reopens.
10. Revisit them on a cadence. This is the step teams skip. Review the agreements in a retrospective, at quarterly checkpoints, and every time someone joins or leaves. Norms die from neglect, not from disagreement.

If your team runs in sprints, Scrum.org and Swarmia both describe the same ritual in agile terms, with sprint-context examples you can borrow.

Team working agreements: 30+ examples to copy

Vague values do not survive contact with a real team. “Be respectful” tells nobody what to do on Monday morning. Start instead from concrete, observable agreements and adapt the specifics to your team. Here is a starter set you can copy today, one for each of the four areas that produce the most friction.

A starter agreement you can copy

• Communication: “We debate in the open channel, not in DMs, and reply to chat within four working hours.”
• Meetings: “No agenda in the invite means no meeting. The organizer posts notes and actions the same day.”
• Decisions: “Reversible decisions don’t need a meeting; contested ones name a decider, and we log the outcome within 24 hours.”
• Feedback: “We disagree with the idea, not the person, and raise a concern directly before escalating it.”

Four lines is a working draft, not a finished agreement. Take them into your session as the starting point, change the specifics until they describe your team, and cut anything your team would not actually enforce.

Need more range? The bank below groups concrete agreements by situation. Do not adopt all of them; that would break the five-to-ten rule. Read it as a menu and take the ones that match your friction.

Communication

• “We debate ideas in the open channel, not in DMs, so the whole team sees the reasoning.”
• “We assume positive intent and ask one clarifying question before reacting to a message.”
• “If a thread passes ten replies, we move it to a short call and post the summary back.”
• “Written status goes up by 10:00 so nobody has to chase an update.”
• “Bad news travels first and fast; we would rather hear a problem early than a surprise late.”

Meetings

• “No agenda in the invite means we decline the meeting.”
• “We start on time and don’t recap for latecomers.”
• “Every meeting names the decision it needs to make, or it becomes a written update.”
• “The organizer posts notes and actions the same day.”
• “Wednesday afternoons are meeting-free for focus work.”
• “Anyone can say ‘let’s take this offline’ without it being rude.”

Decisions

• “Reversible, two-way-door decisions don’t need a meeting; post the plan and proceed.”
• “If we can’t reach consensus in ten minutes, [role] decides and the rest of us disagree and commit.”
• “Decisions made in a meeting get logged within 24 hours.”
• “We name who the decider is at the start of any contested topic.”
• “We reopen a logged decision only with new information, not a new mood.”

Remote and async work

• “Core overlap hours are 10:00 to 13:00 [timezone]; we schedule live calls only then.”
• “Everyone keeps their working hours and timezone visible on their calendar and status.”
• “Async is the default; we book a call only when a written thread has stalled.”
• “We write updates so they still make sense to someone reading them eight hours later.”
• “Calls that some people can’t attend get recorded, so no timezone is penalized.”

Response times

• “Chat gets a reply within four working hours; email within one working day.”
• “Nothing is expected outside your posted working hours.”
• “Anything urgent goes through a call or the on-call path, not a chat message.”
• “Pull requests get a first review within one working day.”
• “If you can’t answer fully, you acknowledge the message and say when you will.”

Conflict and feedback

• “We disagree with the idea, never the person, and never in DMs.”
• “Feedback is specific and about behavior, not about character.”
• “We raise a concern with the person directly before escalating it.”
• “Saying ‘I don’t agree’ in a meeting is welcome; silence is not agreement.”
• “When something festers for more than a week, we escalate to [role] instead of stewing on it.”

Vague agreements are useless

There is one test for whether something belongs on the list. If a stranger watching your team could not tell whether you were following the agreement, it isn’t an agreement; it is a wish. These are the usual suspects, and what each becomes when you make it observable.

Vague (a wish)	Concrete (you could film it)
Be respectful	We don’t interrupt, and we argue with the idea, not the person
Communicate well	Written status by 10:00; chat answered within four working hours
Be transparent and honest	Decisions get logged within 24 hours
Support each other	Pull requests get a first review within one working day
Have fun	Delete it; it is a hope, not an agreement

A real working agreement, and how the team keeps it alive

Everything above is advice. Here is what it produced on one of our own teams at TeamRetro, who built their agreement by following the same steps this chapter describes.

The board is called Team agreements and carries one line of context: “These are the things we agree on as a team.” Permissions are set so that everyone can propose or add agreements, and the field at the top of the list reads “Propose agreement…”. That setting is this chapter’s argument in product form. If only the lead can add a line, the list stops being an agreement and starts being a policy.

These are the six agreements the team runs on, word for word:

• Our showcase presentations are to get feedback and are short but meaningful
• It’s okay to call a “lights out” during hack sessions to work on tasks
• Anyone can run a “Clear the plate” session to finalise tasks.
• We add our blockers to standup - it’s okay to get help.
• We ask for progress feedback on projects at the 10%, 70%, 90% mark
• We add reasonable deadlines and due dates for our Linear tasks.

Read them again and notice what is missing. Nothing about respect, nothing about trust, nothing you could print on a mug. Every line names something this team actually does: showcases, hack sessions, standup, the way the work is tracked. They would be close to useless for your team, and that is the point. An agreement is only observable if it describes the real ritual it governs.

The list is six lines long, not thirty. That is the five-to-ten rule applied by a team that had to live with the result.

Three of the six carry a comment thread, and that matters more than the wording does. The agreements sit next to the team’s retrospectives, so they get pulled up from time to time as a reference. If a showcase runs long, or if someone is not sure whether calling a lights out is really fine this week, the line is there to point at, and the conversation happens on the agreement itself instead of in a side channel. When the conclusion is that the agreement is wrong, the team edits it. New lines get proposed as the work changes, and lines nobody uses anymore get dropped.

That is the whole lifecycle on one board: write it together, keep it where the team already looks, reference it when something slips, and change it as the team and the work evolve.

Keeping agreements alive: the wall-art problem

Most working agreements die the same way. The team runs a good session, writes a thoughtful list, pins it somewhere, and never looks at it again. Six months later it is wall art: a brilliant set of ground rules nobody references when they are broken. That is the single most common failure on this topic.

Two things keep agreements alive. The first is teeth: when someone crosses an agreement, somebody points at it, calmly, in the moment. An agreement no one enforces teaches the team that none of them count. The second is revisiting on a schedule. Fold a quick review into your retrospectives, revisit the whole set when the team changes shape, and use a recurring team health check to surface the norm that is quietly slipping before it turns into a fight.

This is a follow-through problem at heart, and follow-through is trackable. When an agreements review becomes an action with an owner and a due date rather than a good intention, it gets done. TeamRetro’s own data across a sample of hundreds of thousands of retrospective action items found that about 73% get completed, evidence that commitments a team writes down and returns to do get honored. The agreements that stick are the ones wired into a ritual the team already repeats.

If you have read the defrosting a cold team chapter, this is the refreeze step: icebreakers thaw a group, and agreements lock the new warmth into a habit. Because agreements are a social contract the team writes for itself, they hold better than rules handed down, a framing we develop in creating social contracts with team agreements. Remote and distributed teams lean even harder on the written agreement, since the ambient office cues that carry norms are gone; the remote and distributed dynamics chapter goes deeper, and GitLab’s async handbook is the reference implementation.

Run your working-agreements session in TeamRetro

A working-agreements session maps almost exactly onto how a retrospective board works, which is why teams often run it in TeamRetro. Everyone adds proposed agreements as cards at the same time, silently, so the quieter people and the person in the awkward timezone get the same airtime as whoever usually fills the silence. You group the similar cards, vote to surface the ten that matter most, and turn the survivors into a shared document the team owns. Start from the examples above as your template: add them as cards, then reword and cut them together until the list is yours. Because it sits next to your retrospectives and health checks, the revisit step stops being a calendar reminder you ignore and becomes part of a ritual you already run.

This chapter is part of our team dynamics guide. If you are formalizing this at kickoff rather than mid-flight, the working agreements belong inside a wider team charter: purpose, goals, roles, and decision rights, with these behaviors as the how. If your team runs agile, the scrum master’s retrospective guide covers where agreements get revisited from sprint to sprint. When you are ready, start a free TeamRetro trial and build your first agreement with the team this week.

Frequently asked questions

What is a team working agreement?

A team working agreement is a short, co-created set of rules for how a team works together: how they communicate, run meetings, make decisions, and give feedback. It is deliberate rather than assumed, written down rather than left to habit, and agreed by the whole team rather than handed down by a manager. Most teams keep five to ten and revisit them as the team changes.

What is the difference between team norms and working agreements?

Team norms are the informal, often unspoken standards that form from how a group behaves. Working agreements are those norms made deliberate: a set the team discusses, writes down, and agrees to follow. Every team has norms; not every team has working agreements. Agreements are the version you chose on purpose.

What are some examples of team working agreements?

Good agreements are concrete and observable, such as “no agenda in the invite means we decline the meeting,” “chat replies within four working hours,” “decisions get logged within 24 hours,” and “we disagree with the idea, not the person.” If a stranger couldn’t tell from watching whether you followed it, it isn’t an agreement.

How many working agreements should a team have?

Start with five to ten. A long list is an ignored list. Pick the few agreements that fix your team’s real friction, such as meetings, response times, and how decisions get made, and add more only when a genuine problem appears. You can revisit and adjust the list later.

What is the difference between working agreements and a team charter?

A team charter is the broader kickoff document: why the team exists, its goals, roles, and how it makes decisions, usually set once at the start. Working agreements are the day-to-day behavior rules inside it, and they get revisited far more often. The charter is why and who; the agreements are how.

How do you make working agreements stick?

Co-write them with the whole team so they are owned rather than imposed, keep the list short, and post them where the work happens. The step teams skip is revisiting them: in retrospectives, at quarterly checkpoints, and whenever someone joins. An agreement nobody references when it is broken is just wall art. Turning the review into a recurring action with an owner is what makes the follow-through actually happen.