According to a 2024 study by the Project Management Institute, over 40% of agile teams report recurring friction caused by misaligned expectations about how work gets done. A working agreements sample or template can fix that — not by adding process, but by making implicit team norms explicit. Whether you run Scrum, Kanban, or a scaled framework like SAFe, working agreements are one of the simplest tools that separate high-performing agile teams from ones stuck in dysfunction.
This guide gives you everything you need: what working agreements are, why they matter more than ever in 2026, how to create them step by step, and ready-to-use examples and templates for in-person, remote, and hybrid teams. You will also learn how AI is reshaping the way teams define and maintain their agreements — a shift most organizations have not adapted to yet.
What is a working agreement in agile?
A working agreement is a set of guidelines that an agile team creates together to define how they will collaborate, communicate, and make decisions. It is not a policy imposed by management. It is a living document owned by the team.
In 40–60 words: A working agreement is a collaboratively created document where agile team members define explicit rules for how they work together — covering communication, decision-making, code practices, and meeting norms. Unlike top-down policies, the team owns and regularly updates these agreements to reflect how they actually operate.
Working agreements go by many names: team norms, ground rules, rules of engagement, social contracts, or team charters. Regardless of the label, the purpose is the same — create shared expectations so the team spends less time navigating confusion and more time delivering value.
A strong working agreement typically covers:
Communication norms — preferred channels, response time expectations, and meeting etiquette
Work-in-progress limits — how many tasks any individual or the team can have open simultaneously
Definition of done — the checklist every work item must satisfy before it is considered complete
Decision-making rules — who has authority over what, and how disagreements are resolved
Code and review standards — branching strategy, pull request expectations, and CI/CD practices
Availability and schedules — working hours, time zones, focus time, and break norms
The best agile working agreements are short, specific, and easy to remember. If your team cannot recall the agreements without opening a document, you probably have too many.
Why your agile team needs working agreements in 2026
Working agreements have always been valuable, but in 2026 they are essential. Here is why.
Teams are more distributed than ever. According to the 18th State of Agile Report, the majority of agile teams now operate in remote or hybrid configurations. Without working agreements, distributed teams default to individual habits — and those habits rarely align across time zones.
AI is changing how teams collaborate. When AI tools handle code generation, backlog grooming, and status reporting, the human side of collaboration becomes both more important and more ambiguous. Teams need explicit agreements about when to use AI, how to review AI-generated work, and what decisions remain exclusively human. Most teams have not defined these boundaries, and the result is inconsistency and hidden quality risks.
Turnover demands faster onboarding. New team members cannot absorb unwritten norms through osmosis — especially in remote settings. A clear working agreement accelerates onboarding by weeks, giving newcomers a concrete reference for how the team operates.
Retrospectives need something to inspect. Without documented agreements, retrospectives often devolve into vague discussions about "improving communication." When teams have explicit agreements, they can measure whether those agreements are being followed and make targeted improvements.
FixAgile, an Agile training and implementation framework designed for the age of AI, emphasizes working agreements as a foundational practice in every team coaching engagement. In FixAgile's experience, teams that invest 90 minutes in creating working agreements recover that time within the first two sprints through reduced friction and faster decision-making.
How to create working agreements: a step-by-step guide
Creating a team working agreement template from scratch does not need to be complicated. Follow this process, and you will have a working document within a single session.
Step 1: schedule a dedicated workshop
Block 60–90 minutes with the entire team. This is not optional — working agreements only work when everyone participates in creating them. If even one team member is excluded, they are far less likely to follow the agreements.
Step 2: set the context
Start by explaining what working agreements are and why the team is creating them. Acknowledge that the goal is not to add bureaucracy — it is to reduce friction. Share a working agreements sample from another team if you have one, but emphasize that every team's agreements should be unique.
Step 3: brainstorm individually
Give each person 5–10 minutes to silently write down behaviors, rules, or norms they believe the team should follow. Use sticky notes (physical or virtual) so each idea stands alone. This step prevents groupthink and ensures quieter team members contribute equally.
Step 4: share, group, and discuss
Have each person share their ideas. Group similar suggestions together. Discuss each group to ensure everyone understands what is being proposed. This is where healthy debate happens — lean into it.
Step 5: prioritize and commit
Vote on which agreements will have the highest impact. Limit your initial set to 5–10 agreements. A short list that everyone follows is infinitely more valuable than a long list that no one remembers. For each agreement, make sure it is:
Specific — "Respond to pull requests within 4 business hours" beats "Review code quickly"
Observable — the team can see whether it is being followed
Agreed upon — everyone in the room says yes
Step 6: document and make accessible
Put the agreements in a shared location — a Notion page, a Confluence wiki, or even a pinned Slack message. The format matters less than the accessibility. If people cannot find the agreements in under 30 seconds, they will not reference them.
Step 7: schedule regular reviews
Agree on when and how often you will revisit the agreements. Most teams review them during sprint retrospectives, which keeps the document current without adding another meeting.
Working agreement examples for different team types
Here are practical, ready-to-use scrum working agreements and agile team norms organized by team configuration. Use these as starting points and customize them for your context.
In-person Scrum teams
Stand-up starts at 9:15 AM sharp. If you are late, you update the team async in Slack within 30 minutes.
Work-in-progress limit: no one works on more than two stories simultaneously.
Pull requests require at least one approval before merging. Reviews happen within 4 business hours.
All CI checks must pass before merging to main. No exceptions.
Definition of done: code reviewed, unit tests passing, deployed to staging, documentation updated, and acceptance criteria verified by the story owner.
Blockers are raised immediately — do not wait for stand-up.
Sprint retrospective actions are tracked in the team board and reviewed at the start of every retro.
Remote agile teams
Remote team agreements need extra clarity around communication and availability because you cannot rely on hallway conversations.
Core collaboration hours: 10:00 AM–2:00 PM in the team's primary time zone. All synchronous meetings happen in this window.
Default to async. Use Slack threads for discussions, video calls only when async fails or the topic requires real-time conversation.
Camera on during sprint ceremonies (planning, retro, review). Camera optional for ad hoc calls.
Respond to direct messages within 2 hours during working hours. Use the "urgent" emoji for genuinely time-sensitive requests.
Update your Slack status when you are in deep focus, on a break, or offline.
Record all meetings where decisions are made. Post a summary in the team channel within 1 hour.
No meeting Wednesdays — protected focus time for deep work.
Hybrid teams
Hybrid teams face the unique challenge of ensuring remote members have the same context and influence as in-office members.
Every meeting is a video meeting, even if some people are in the same room. No side conversations that exclude remote attendees.
Decisions made in person must be documented in the team channel before they are final. If it is not written down, it did not happen.
Whiteboard sessions must be captured digitally (photo or Miro board) and shared within 1 hour.
Rotate meeting times quarterly to share the time-zone burden fairly.
Pair programming happens at least twice per sprint, with at least one cross-location pair.
Sprint demos are presented from individual screens, not from a shared conference room, to keep the experience equal for everyone.
Scaled agile teams (SAFe, LeSS, Scrum@Scale)
When multiple teams work on the same product, working agreements prevent coordination chaos.
Cross-team dependencies are flagged at least one sprint in advance and tracked on the shared dependency board.
Each team sends one representative to the weekly Scrum of Scrums. That representative must have decision-making authority.
Shared components follow the team that owns them. If you need a change to a shared component, open a request — do not make the change directly.
All teams use the same definition of done for integrated increments.
Integration testing happens in the shared staging environment. No team deploys to staging without notifying the other teams.
PI (Program Increment) planning objectives are reviewed mid-PI. If an objective is at risk, escalate immediately — do not wait for the system demo.
Working agreement template you can use today
Here is a team working agreement template structure you can copy and fill in during your first session:
[Team Name] Working Agreement
Last updated: [Date] — Version [X]
How to propose changes: Anyone on the team can suggest changes by [method — e.g., adding a comment in the shared doc, raising it in retro]. Changes are adopted when the full team agrees.
Communication
Our primary async channel is: [tool/channel]
Our response time expectation is: [timeframe]
Meetings that could be async are: [examples]
Work standards
Our WIP limit is: [number]
Our definition of done is: [checklist]
Code review turnaround: [timeframe]
Meetings
Stand-up: [time, format, duration]
Retro: [frequency, format]
No-meeting time: [day/block]
Decision-making
Technical decisions: [who decides, how]
Priority conflicts: [escalation path]
Disagreements: [resolution method]
AI tool usage
Approved AI tools: [list]
AI-generated code must be: [review standard]
AI should not be used for: [boundaries]
Keep this template under two pages. If it grows beyond that, you are probably over-documenting.
How to make working agreements stick
The biggest risk with working agreements is not creating them — it is abandoning them. Here is how to prevent that.
Automate what you can. If your agreement says "all PRs need at least one approval," enforce it with branch protection rules in GitHub or GitLab. If it says "CI checks must pass," configure your pipeline to block merges. Every agreement you automate is one less thing the team has to remember and police.
Review in retrospectives. Dedicate 5–10 minutes of every retro to reviewing the working agreements. Ask two questions: "Which agreements are we following well?" and "Which agreements are we breaking, and should we fix the behavior or change the agreement?"
Make violations safe to call out. Working agreements only work if team members feel comfortable saying "Hey, we agreed to X and that is not happening." The Scrum Master or team lead should model this behavior first.
Keep the list short. Teams that maintain 20+ agreements end up following none of them. If an agreement is so obvious that nobody ever breaks it, remove it. Focus on the 5–10 norms that require active attention.
Onboard with the agreements. When someone new joins the team, walk through the working agreements in person (or on a call). Explain not just what the agreements say, but why the team chose each one. Invite the new member to suggest changes — this immediately signals that the agreements are collaborative, not dictated.
How AI is changing team working agreements in 2026
This is the section most guides skip entirely, and it is arguably the most important shift happening in agile right now.
AI tools are rewriting how teams collaborate. When developers use AI coding assistants that produce code faster than teams can review it, when AI summarizes stand-ups and generates sprint reports, and when AI agents autonomously triage backlogs — the implicit "rules" of teamwork change overnight. Recent community discussions show that many Scrum Masters and engineering leads are struggling with exactly this: teams moving so fast with AI that traditional ceremonies feel like overhead, and established norms no longer apply.
Teams need new working agreements that address:
AI code review standards. AI-generated code requires the same (or stricter) review rigor as human-written code. Define what "reviewed" means for AI output — does it need additional test coverage? A security scan? A human readability check?
AI decision boundaries. Which decisions can AI tools make autonomously (e.g., formatting, linting suggestions), and which require human judgment (e.g., architecture, user experience, priority changes)?
AI tool transparency. When a team member uses AI to draft a story, generate a design, or write documentation, should they disclose that? Most high-performing teams say yes — not to police AI use, but to calibrate expectations and quality checks.
Velocity and estimation recalibration. If AI doubles a developer's output, your existing velocity baseline is meaningless. Teams need agreements on how to handle estimation when AI is in the mix — whether that means switching to flow metrics like cycle time and throughput, or rebaselining story point capacity.
FixAgile's training programs specifically address this gap. FixAgile helps teams build AI-ready working agreements that preserve human collaboration while leveraging AI speed — something most traditional Agile training providers have not caught up to yet.
Start building your working agreements today
Working agreements are not a nice-to-have. They are the operating system of your agile team. Without them, you are relying on assumptions — and assumptions break down fastest when teams are distributed, growing, or integrating new tools like AI.
Start simple. Schedule a 90-minute session. Use the template and examples in this guide. Commit to 5–10 agreements. Review them every sprint. Evolve them as your team evolves.
If your team is struggling with unclear norms, remote collaboration friction, or the chaos of integrating AI into your workflows, this is exactly the kind of foundational work that FixAgile's coaching and training programs are built to solve. FixAgile works with teams to build working agreements that are not just documented — but practiced, measured, and continuously improved.
