Team Working Agreement: 10 Clauses, Example and Template

Every team has the same three arguments on repeat. Did anyone actually agree to that? Whose task was this? Is it done, or is it "done"? Each one costs a meeting, and none of them is about the work itself.

The direct answer: a team working agreement is the short list of rules a team writes down so it stops re-arguing them: how fast people reply, where decisions get recorded, who assigns a task, and what done means. It matters because unclear expectations cost a team. In Gallup's survey of 21,648 U.S. employees, fielded August 5 to 19, 2026 and published October 28, 2026, engagement fell to 29%, the lowest since 2011, and Gallup tied the drop to lower ratings on knowing what is expected at work.

In short. A team working agreement is eight to ten written rules about how a team behaves, not what it delivers. Write it together in one session, keep it to one page, and put each rule where the work happens: ownership on the task, decisions in the task's comments, done as a status. An agreement that lives only in a document is forgotten within a month.

What is a team working agreement?

A team working agreement is a set of behaviour rules the team owns. It is narrower than the documents it is usually confused with, and that narrowness is the point: each clause should settle one recurring argument.

A definition of done can sit inside the working agreement as one clause. The charter and the RACI should not; they answer different questions and are owned by different people.

Ten clauses a project team working agreement needs

Pick the clauses that end your team's real arguments. Ten is a ceiling, not a target.

1. Reply times. "Mentions get a reply within one working day; anything urgent goes by phone, not chat."
2. Where decisions are recorded. "A decision that changes a task is written as a comment on that task." The reasoning is in task comments vs a chat channel.
3. One owner per task. "Every task has one assignee. Others who help are collaborators, not co-owners."
4. How work is assigned. "Only the project lead, or the task's assignee by agreement, reassigns a task."
5. What done means. "Done means reviewed by someone other than the assignee and accepted against the task's description."
6. Handovers. "Before you hand a task over, the next person can start from the task alone, without asking you."
7. Raising a blocker. "A blocker is raised on the task the same day it appears, with the person who can clear it mentioned."
8. Meetings. "No agenda, no meeting. Decisions from a meeting go onto the tasks they change within a day."
9. Working hours and quiet time. "Core hours are 10:00 to 15:00 in each person's time zone. Nobody is expected to answer outside them."
10. Changing this agreement. "Anyone can propose a change; it takes effect when the team accepts it at the next review."

A team working agreement example

Here is a filled example for a six-person team delivering a client website over twelve weeks: a project manager, two developers, a designer, a content writer and a QA lead.

Website rebuild: how we work (agreed week 1, review at each phase gate)

1. We reply to an @mention within one working day. Urgent means a phone call.
2. Decisions that change scope, dates or design are written as a comment on the affected task, with the decider named.
3. Every task has one assignee. The designer and QA lead join tasks as collaborators.
4. Only the project manager reassigns work between people.
5. A page is done when QA has checked it on mobile and desktop and the content writer has signed off the copy.
6. Client feedback is copied onto the task it affects the same day, not left in email.
7. Blockers go on the task by 16:00, mentioning whoever can clear them.
8. The Tuesday check-in is 20 minutes and has an agenda by Monday noon.
9. Core hours are 10:00 to 15:00 local time.
10. This list changes at a phase gate, by team agreement.

A team working agreement template

Copy this into your kickoff notes and fill each blank in the session. Delete any line your team does not argue about. If you are running that session as part of a project start, the kickoff meeting template has a slot for it.

TEAM WORKING AGREEMENT: [team or project name]
Agreed on: [date]          Next review: [date or checkpoint]

1. Replies: we answer an @mention within [time]. Urgent means [channel].
2. Decisions: recorded as [where], with [who decided] named.
3. Ownership: every task has one [assignee]; helpers are [collaborators].
4. Assignment: [who] may reassign a task, and only [when].
5. Done means: [the check, and who performs it].
6. Handover: the next person can start from [the task / a handover note].
7. Blockers: raised on [where] within [time], mentioning [who].
8. Meetings: [agenda rule]; decisions move to [where] within [time].
9. Hours: core hours [time]; no reply is expected outside them.
10. Changes: proposed by anyone, accepted at [review checkpoint].

How is an agile team working agreement different?

On a Scrum team the agreement usually sits beside the definition of done and is reviewed at each sprint retrospective, because the retrospective is already the meeting where the team inspects how it works. The clauses lean toward ceremonies (when the daily stand-up starts, what may enter a sprint after planning) rather than handovers between phases. The content changes; the rule that the team writes and revises it does not.

How do you make a working agreement stick?

A working agreement fails the same way a new-year resolution does: it lives in a document nobody opens. The fix is to put each rule where the work already happens, so following it is the easy path. The diagram below maps four of the clauses to the place in the plan that enforces them.

In Onplana, a task has one accountable assignee and up to 20 collaborators who can update it but cannot reassign it, which is clause 3 enforced by the tool rather than by memory. Every task carries its own comment thread, and an @mention notifies the person with a link straight to the comment, so clause 2 has a natural home. A Review column on the Kanban board makes "done means reviewed" visible as a step, and each person's notification settings turn email and phone push on or off and keep push quiet overnight. The team collaboration features page shows how those pieces fit on one plan, and team accountability on one plan covers the ownership clause in more depth.

Write it once, then let the plan carry it

A working agreement is not a culture document. It is ten lines that end ten arguments. Write it together, keep it to one page, review it at a fixed checkpoint, and move every clause you can out of the document and into the plan your team already opens each morning. The clauses that still need the document after that are the ones worth reviewing.