Team Working Agreements: Template and Workshop

Team working agreements are the ground rules a team sets for itself: when we are reachable, how quickly we respond to reviews, which meetings we actually need and what happens when things get tense. That sounds like bureaucracy. In reality it is the opposite. Every team already has rules like these, they just aren’t written down anywhere. They live in people’s heads, in habits and in the quiet annoyance when someone “breaks” a rule they never knew existed.

This topic matters to me because a lot of friction in teams isn’t really conflict between people. It is unspoken expectations colliding. One person expects a chat reply within ten minutes, another checks twice a day and calls that focused work. Both are right, as long as nobody talks about it. In this article you get a template, a tried-and-tested workshop format and my view on what leaders should do here and what they had better leave alone.

In short

Working agreements make a team’s unwritten rules visible and negotiable, for example around availability, reviews, meetings and decisions. They only work when the team phrases them itself, makes them checkable and reviews them regularly. The biggest pitfall is a list handed down from above that then disappears into a drawer.

What you will learn in this article

• What working agreements are and how they differ from a Definition of Done and a team charter
• Which topics belong in a good agreement, with a template to copy
• How to facilitate a 90-minute workshop step by step
• How to phrase agreements so they can be checked and kept alive
• What your role as a leader is in all of this

What are team working agreements?

A working agreement is a short, written agreement about how a team works together. It isn’t about the product or the architecture, but about collaboration: communication, times, workflows, how you deal with mistakes. In German teams you often hear “Teamvereinbarung” or “Spielregeln”. The English term has become standard in agile teams, and it is also what you will find in tools and templates.

The key word is “agreement”. An agreement is something everyone has said yes to. A rule announced by the team lead via email may be sensible, but it is not a working agreement. This distinction sounds like hair-splitting, yet it decides whether anyone will later feel bound by it.

How they differ from a Definition of Done, a team charter and company rules

Working agreements are often confused with other artifacts. This overview helps to sort them out:

By the way, the Scrum Guide doesn’t mention working agreements. It describes teams as self-managing, meaning they decide internally who does what, when and how. Working agreements are an obvious tool for exactly that. The Kanban Guide is more explicit: its “Definition of Workflow” includes explicit policies on how work flows through each state. So part of your working agreements can live right there.

Why team working agreements beat unwritten rules

Unwritten rules have three problems. First, not everyone knows them, especially new colleagues. Second, everybody interprets them a little differently. Third, they are hard to talk about, because officially they don’t even exist. Whoever says “that’s how we do it here” rarely has anything everyone can point to.

A written working agreement shifts the conversation. When something goes wrong, we no longer talk about the person (“You never reply”), but about the agreement (“Our availability agreement isn’t working right now, why?”). That takes a lot of pressure out of situations that otherwise get personal fast. It also makes onboarding easier. New team members can read in ten minutes what others need months of observation to figure out.

Especially in remote and hybrid teams this is no luxury. If you don’t bump into each other in the office, you can’t align expectations on the side. My article Leading remote teams: rituals that actually work fits here too, and working agreements play a supporting role in it.

Which topics belong in working agreements?

There is no mandatory list. Good working agreements start where the team actually struggles. Still, certain areas show up in almost every team. The following questions help you find blind spots.

Availability and communication

When are we all reachable, and when is focus time? Which channel is meant for what, for example chat for quick things, tickets for tasks, a call for urgent matters? What response time is normal, and how does someone recognise that something really is urgent? That last question alone saves a lot of stress, because otherwise every message feels urgent.

Meetings and rituals

Which meetings do we really need, and who has to be there? Are there meeting-free times? Camera on or off? Do we start on time even if someone is missing? An honest look at the calendar pays off here. Often the strongest working agreement is one that gets rid of a meeting.

Code reviews and working on code together

How quickly do we react to pull requests? How big may a PR be? Who is allowed to merge? How do we phrase comments so they land well? I wrote about that last point in detail in Code review feedback: comments that land. These days an agreement on AI tools belongs here as well, for instance whether AI-generated code is labelled in the PR.

Flow, decisions and conflicts

How many tasks do we have open at the same time? Who decides what, and how? What do we do when we disagree? How do we give each other feedback? These questions are less comfortable than asking about core hours. That is exactly why they belong on the list. For team decisions, consent decision-making or the advice process work well, for example.

Template: team working agreements to copy

The following template is a starting point for a fictional team’s everyday work, not a finished rulebook. Take the areas that matter to you and drop the rest. The third column is especially important to me: it describes how you notice whether the agreement works.

A rule of thumb: five to ten agreements are enough. Whoever writes down 30 points ends up with a handbook nobody reads. Better a few that people actually live by.

Creating team working agreements: a 90-minute workshop

This is how I would run a workshop for a team of five to nine people. It works on site with sticky notes just as well as remotely with a digital whiteboard. Plan for 90 minutes. If you already have working agreements and only revise them, 60 is often enough.

Preparation

A week before, send the team three questions that everyone answers on their own: What bothers me about how we work together right now? What works well and should stay that way? What do I need to do good work? In addition, clarify upfront which external requirements apply and are not negotiable. Put them on the table at the start so nobody is disappointed later.

Step-by-step agenda

1. Opening (10 minutes): Explain the goal and the ground rules of the workshop. Name the non-negotiable requirements. Make it clear that the result is a first draft, not a constitution.
2. Collect pain points (15 minutes): Everyone silently writes down their own points, ideally from the preparation. One note per thought. Then each person briefly presents their notes, without discussion.
3. Cluster and choose (10 minutes): Group the notes into themes such as availability, reviews or meetings. With dot voting, the team picks the three to five themes that hurt most.
4. Phrase agreements (25 minutes): In pairs or groups of three, draft one proposal per theme following the pattern “We …, so that …”. Add the criterion that shows it works.
5. Decide (15 minutes): Each proposal is read out. You don’t ask “Does everyone love this?” but “Is there a serious objection to trying this for four weeks?”. Objections improve the proposal instead of blocking it.
6. Agree on upkeep (10 minutes): Clarify where the agreements live, when you review them and who triggers the review.
7. Closing (5 minutes): Quick round: on a scale from 1 to 5, how confident are you that we will live this? Scores below 3 are a signal you should take seriously.

Expected result: A list of three to seven agreements, each with a reason and a check criterion, plus a date for the first review in four weeks.

Working agreements are created and improved in a cycle.

Good phrasing: checkable, positive, justified

Most working agreements don’t fail because of the idea, but because of the wording. Everyone signs “We communicate openly and respectfully”. Nothing will change, though, because nobody knows what exactly it means. Three criteria help to sharpen it:

• Checkable: An outsider could observe whether you stick to it.
• Positive: Describe what you do, not only what is forbidden.
• Justified: The “so that” explains which problem the agreement solves. If the problem goes away, the agreement may go too.

An example from a fictional team that looks after a bakery’s online shop. Before, it said: “Reviews should happen promptly.” After: “We look at pull requests up to 200 lines on the same working day, so that nobody has to start a new task with half-finished work on their mind.” The second sentence is longer, but everyone knows what is meant and why.

Keeping team working agreements alive

An agreement that is decided once and never looked at again turns into decoration. That is why the last workshop step matters so much. A short traffic light in every second retrospective has proven useful: each agreement gets green (works), yellow (wobbly) or red (we don’t live it). You talk about yellow and red, not about green. It takes ten minutes.

There are also occasions when you should revisit the list outside the usual rhythm: when someone new joins the team, when the team changes a lot, when the nature of the work changes or when an agreement is repeatedly not kept. In its Team Playbook, Atlassian also recommends a fixed cadence, about once a quarter.

What if someone doesn’t stick to it?

Ask first, don’t judge. Often there is a good reason behind it: the agreement doesn’t fit that person’s work, they weren’t at the workshop, or the agreement was unrealistic from the start. Address it promptly and one-on-one, referring to the agreement rather than to someone’s character. If the pattern repeats with several people, it isn’t a discipline problem but a hint that the agreement needs to be revised.

The leader’s role in working agreements

I have a clear opinion here: as a leader, you facilitate, you don’t dictate. If the team lead writes the list and the team nods it through, you have a rule with a friendlier name. Everyone notices, at the latest during the first conflict.

That doesn’t mean you stay quiet. You bring in the requirements that come from outside and label them as such. You make sure quieter voices are heard too, for example by collecting silently before every discussion. And you stick to the agreements yourself. Nothing devalues a focus-time agreement faster than a team lead who books meetings right in that slot.

I also draw a line: working agreements are not a tool for performance reviews. Whoever pulls them out as a checklist in an appraisal turns a team agreement into a control instrument. After that, nobody writes honest agreements anymore.

Common mistakes and how to avoid them

• Too many points: Nobody remembers 25 agreements. Start with a few and only add more when there is a real need.
• Too vague: “We are respectful” can’t be checked. Ask for every point: how would we notice that we aren’t doing it?
• Imposed from above: Without real participation, the feeling that these are “our” rules is missing.
• Well hidden: The list sits in a wiki subfolder nobody can find. Link it in the team channel and on the board.
• Never reviewed: Without a fixed review date, agreements quietly become outdated.
• People instead of behaviour: Agreements that obviously target a single person poison the atmosphere. Phrase them for everyone.

FAQ

What is the difference between working agreements and the Definition of Done?

Working agreements cover how the team works together, i.e. communication, times and workflows. The Definition of Done describes when a piece of work counts as finished. Both complement each other and should be maintained separately.

How many working agreements should a team have?

Three to seven are enough to start, rarely more than ten in the long run. More important than the number is that each agreement solves a real problem and can be checked.

Who should facilitate the workshop?

That can be the leader, a Scrum Master or a neutral person from another team. If there is tension between the team and its leader, neutral facilitation is usually the better choice.

Are working agreements part of the Scrum Guide?

No. The Scrum Guide describes teams as self-managing and names the retrospective as the place for improvements. Working agreements are a common tool to put exactly that into practice.

How often should you review working agreements?

A short traffic light in every second retro has proven useful, plus a more thorough revision about once a quarter or when the team changes significantly.

Your next step

You don’t have to schedule a workshop right away. Ask a single question in your next retro: “Which unwritten rule do we have that someone should write down?” The answers often already contain your first two or three working agreements. If you as a leader also want to explain how you work yourself, my guide to the manager README helps. You will find more guides on collaboration in the blog.

Over to you: which agreement has changed the most in your team, or which one do you miss most right now? Feel free to tell me in the comments.

Sources

• Atlassian Team Playbook: Working Agreements
• The Scrum Guide (2020)
• The Kanban Guide

This post was created with AI assistance.

👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.

📬 Stay updated: New articles on serverless, AI and leading tech teams via RSS, browser push or the weekly newsletter (in German).

Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en