Working Agreements: Examples for Agile and Non-Agile Teams

What counts as a working agreement?

working agreements examples is a key topic in modern project management and teamwork. A working agreement is a norm the team has explicitly chosen and written down, usually in language specific enough to be observed. “Communicate well” is a value. “Decisions are logged in the project doc within 24 hours” is an agreement.

Atlassian’s Team Playbook describes them as shared norms for how a team works together, communicates, and collaborates, whether people sit together or across time zones. That definition is useful because it does not limit agreements to meetings: anything the team does repeatedly is fair game.

Three neighbouring documents are often confused with them:

The distinction matters because teams try to solve operational friction by rewriting the charter, which is like fixing a squeaky door by repainting the house.

What are good examples of working agreements?

The best examples are specific, observable, and tied to friction the team has actually felt; vague norms change nothing.

> Common mistake: copying another team’s list. Their agreements encode their friction. A remote design team’s “cameras optional” rule may be irrelevant to a warehouse team, and a warehouse team’s handover rule may be the single most valuable line for a hospital ward.

What changes for agile teams?

Agile teams need behavioural agreements plus a small set of process agreements, because the process is visible and therefore negotiable.

The process layer usually covers:

• Readiness and completion. What must be true before an item enters a sprint, and what must be true before it counts as done.
• Ceremony expectations. Who attends which event, what preparation is required, and what “on time” means for a distributed team.
• Work in progress. A WIP limit per person or per column, agreed in advance so that pulling extra work is a conversation rather than a silent decision.
• Interruptions. What qualifies as an emergency that may enter the sprint, who decides, and what gets displaced.
• Estimation. The scale in use, who estimates, and what happens when the team disagrees.

Two agile-specific pitfalls are worth naming. A team can accumulate so many process agreements that the agreements become the process, and the retrospective turns into a rules review. And sprint commitments can get treated as promises to stakeholders rather than forecasts to the team, which quietly kills the honesty that made the agreements useful.

What changes for non-agile teams?

Non-agile teams — agencies, operations, finance, construction, sales — benefit just as much, but their agreements cluster around coordination rather than ceremonies.

Examples that tend to earn their place:

• Client communication: “Status updates go out every Friday by noon, even when there is nothing new.”
• Shift handover: “Handover is written, includes open incidents and pending approvals, and is acknowledged by the incoming lead.”
• Financial close: “Items submitted after the 3rd are booked in the following period; exceptions need the controller’s approval.”
• Construction and field work: “A request for information is answered within two working days or escalated to the project manager.”
• Sales: “Every opportunity above a set value has a next step and a date before it can stay in the pipeline.”

These teams often resist the term “working agreements” because it sounds like agile vocabulary. Call them operating norms or team rules. The label does not matter; the specificity does.

How do you write agreements that survive?

Run it as a short workshop, not an email thread. A 60-minute session with the whole team, plus 10 minutes of preparation per person, is enough for a first version.

1. Collect friction, not opinions. Ask each person for two moments in the last month when the team slowed down because of a coordination gap. Write them on cards without names attached.
2. Cluster the cards. Five to eight themes usually emerge: meetings, channels, decisions, handoffs, feedback, focus, escalation.
3. Draft in observable language. For each theme, write a sentence someone could watch happen. If you cannot tell whether it was followed, rewrite it.
4. Vote, then trim. Each person gets three votes. Keep the top five to eight. Everything else goes to a parking lot with a review date.
5. Name an owner and a review date. An agreement without an owner becomes folklore.
6. Publish where work happens. A board, a pinned doc, a task template — not a folder three clicks deep.

Two design rules do most of the work. Write the behaviour, not the value — “we assume good intent” is a value; “before escalating, ask the person directly” is a behaviour. And prefer defaults over bans — “default to async unless the topic needs debate” gives people a decision rule instead of a prohibition.

What do the numbers look like?

Agreements are cheap to write and hard to defend in a budget conversation, so it helps to translate them into hours.

Example 1: an eleven-person product team

The team measured 6.5 hours of meetings per person per week. After agreeing on “no recurring meetings on Wednesday” and “every meeting needs an owner and a written outcome”, the average fell to 3.8 hours.

• Saving: 2.7 hours per person per week.
• Across 11 people: 29.7 hours per week.
• Across 46 working weeks: about 1,366 hours, or roughly 34 working weeks of a single full-time person.

The team did not reduce output. It reduced the number of meetings that existed only because the previous meeting had no written outcome.

Example 2: an eight-person agency across two time zones

Their design review cycle averaged 5.2 working days, mostly waiting for feedback that arrived in whichever channel the reviewer preferred. They agreed on one review channel, a 24-hour response expectation, and a rule that feedback must be consolidated by the project lead before it reaches the designer.

• Cycle time fell to 3.1 days, a saving of 2.1 days per review.
• With 26 client projects per quarter and roughly two review rounds each, that is 52 rounds.
• Saving: 109 project-days per quarter, about 1.7 working months of capacity recovered.

The decisive line was not the response time. It was “consolidated feedback”, which ended the pattern of a designer receiving four contradictory opinions in sequence.

Example 3: a shift-based operations team

A 24-person team running three shifts had an average of nine incomplete handovers per month, each costing about 40 minutes of rework and occasionally a missed customer commitment. They wrote a three-line handover agreement and required an acknowledgement from the incoming lead.

• Incomplete handovers fell to two per month.
• Recovered time: seven incidents × 40 minutes = 4.7 hours per month, plus a reduction in escalations that the team did not attempt to quantify.

Small numbers, but the second-order effect mattered more: the night shift stopped feeling like a different company.

> Practical tip: measure one number before and one number after. A single before-and-after pair, honestly reported, protects the practice far better than a slide full of principles.

What are the trade-offs?

The real trade-off is between explicitness and flexibility. An explicit agreement reduces negotiation cost but raises the cost of change. A team that writes twenty rules will follow eight and feel guilty about twelve.

There is also a fairness dimension. Agreements written by the loudest people encode their preferences: early meetings, always-on chat, cameras on. A useful test is to ask who the agreement inconveniences, and whether that person was in the room. Atlassian’s testing of its Working Agreements play reported that 74% of employees who ran it felt empowered to speak up about changes they wanted in their team — the process matters as much as the output.

How do you enforce an agreement without becoming the police?

Gently, and in public, and with the agreement itself as the subject rather than the person.

A three-part script works in most situations:

1. Name the agreement, not the person. “We said decisions get logged the same day — this one is still only in chat.”
2. Ask what got in the way. There is usually a real constraint, and it often reveals that the agreement needs adjusting.
3. Offer the fix and move on. “Can you drop it in the doc now, or should I?”

What to avoid: keeping score, raising the agreement only when it suits you, and treating a lapse as a character flaw. An agreement used as a weapon stops being an agreement and becomes evidence.

If the same agreement is broken repeatedly, the conclusion is usually not that people are careless. Either the agreement is unrealistic for the workload, or it was never really agreed. Both are worth discussing in a retrospective rather than in a one-to-one accusation.

What mistakes should you avoid?

• Writing values instead of behaviours. “Respect each other” cannot be observed or reviewed.
• Letting the list grow. Every incident adds a rule; nobody removes one. Review and prune on a schedule.
• Skipping the review. Agreements drift within two quarters as people join, leave, and change roles.
• Making agreements for other teams. If a norm depends on another team’s cooperation, it needs a conversation with them, not a line in your document.
• Confusing agreement with consensus. A team can agree to trial something for four weeks by majority vote. Waiting for unanimity produces bland norms.
• Hiding them in a wiki. Visibility is most of the enforcement mechanism.
• Never testing them. Run one month, measure one number, decide.

Where should the agreements live?

Where the work happens, ideally in the same system. A norm that says “every task has a named owner and a date” is easier to keep when the board enforces the fields. A norm about handoffs is easier to keep when handoffs are visible as state changes rather than messages.

Doitify is our platform, and this is the part it genuinely does well: boards, multi-level tasks and sub-tasks, checklists, owners and due dates, dependencies, workload views, and reports in one place, so agreements can be checked against the actual state of work instead of memory. It is not a substitute for the conversation, and a five-person team with a shared document may not need the extra structure. The point is that an agreement is easier to honour when the evidence is already on screen.

Conclusion

Working agreements are not a culture document. They are a small set of specific, team-authored rules that remove the ambiguity people trip over every week: where decisions live, how fast a reply is expected, what counts as urgent, and who owns the handoff.

Write five to ten behaviours, keep them where work happens, give each one an owner, and put a review date on the list. Then measure one number before and after, because the case for agreements is strongest when it is expressed in hours recovered rather than in good intentions.

If this post on working agreements examples was helpful, you might also enjoy How to Prioritize Tasks at Work (Step-by-Step) and How to Balance Workloads Across a Team (Step-by-Step Guide).