Working Agreements: Examples, Rules & a 4-Step Guide

Key Highlights of Working Agreements

• Working agreements help a team decide how members will work with one another.
• They clarify small but important expectations before problems arise.
• Good working agreements cover communication, meetings, availability, quality, decisions, and delivery.
• Develop team working agreements with input from the whole team.
• They should be short, practical, visible, and easily changed.
• When a team is writing its first set of rules, working agreements are useful examples.
• Remote and hybrid teams may need extra agreements around online communication and availability.
• A Scrum Master can help the team create, review, and improve its working agreements.

Introduction

A team can have skilled people and still struggle to work well together. One person may expect quick replies to messages, while another may check messages only a few times a day. Some people may believe that meetings should start on the dot, while others may believe that a five-minute delay is normal.

Small differences can cause big problems.

That's where working agreements come into play. They are a simple way for a team to decide how its members will work together. The team discusses their expectations and agrees on some basic rules instead of unclear expectations.

For Agile teams, this can be especially useful. Agile ways of working depend on communication, collaboration, trust, and regular feedback. Good team working agreements support all four.

Working agreements are not meant to control every action a person takes. They are not a long list of workplace rules. They are shared commitments created by the team for the team.

In this guide, we will look at working agreements examples, what they should contain, how to create them, and how to keep them useful over time.

What Are Working Agreements?

Definition and Purpose

Working agreements are a set of simple rules or commitments that a team creates together to decide how it will work.

They answer practical questions such as:

• How quickly should we respond to important messages?
• What happens if someone cannot attend a meeting?
• How will we handle disagreements?
• When should meetings start and end?
• How will we review each other's work?
• How do we raise a problem?
• What does "done" mean for our team?

The exact list depends on the team.

The main purpose of working agreements is to remove unnecessary confusion. Team members do not have to guess what others expect because the group has already discussed the important points.

Good agile working agreements also support healthy team behaviour. They can help people speak up, ask for help, give feedback, and take responsibility for their work.

Working Agreements vs Team Norms

Sometimes the words “working agreements” and “team norms” are used synonymously, but there can be a small difference.

Team norms are the shared expectations and behaviors that develop within a group. They’re how people communicate, how they deal with conflict, and how they treat each other.

Working agreements are usually more intentional. The team sits down, discusses what it needs, and agrees on specific behaviours.

For a deeper look at this topic, seeTeam Norms.

For example, a team norm may be that people generally listen without interrupting. A working agreement could make this more specific by saying, "We let the speaker finish before responding."

Both can help a team work better. The main difference is that working agreements are normally discussed and written down as shared commitments.

Where They Sit in the Team Charter

Working agreements can be one part of an agile team charter.

A team charter gives a team a broader picture of how it will operate. It may include the team's purpose, goals, roles, responsibilities, values, and ways of working.

Working agreements are more focused on everyday behaviour.

For example, an agile team charter might explain the team's purpose and goals. Its working agreements might say:

• We start daily meetings on time.
• We raise blockers as soon as possible.
• We do not assign blame when discussing mistakes.
• We review important work before it is completed.

You can also refer to thisAgile Team Charter resource for a broader view of team structure and expectations.

Why Agile Teams Use Working Agreements

Making Expectations Explicit

Many team problems start with an assumption.

A developer assumes that a message marked "urgent" needs an answer within an hour. A designer thinks it can wait until the next working day. Both people may be acting reasonably based on their own expectations.

A working agreement removes that guesswork.

For example:

"Messages marked urgent should receive an acknowledgement within two working hours."

Now the expectation is clear.

This is one reason working agreements for agile teams are useful. Agile teams usually work in brief cycles and need communication on a regular basis. Clear expectations can prevent small misunderstandings from slowing down the work.

Building Accountability and Trust

Trust is easier to build when people know what to expect from each other.

If a team agrees to raise blockers early, members know that problems should not be hidden until the last minute. If the team agrees to give feedback respectfully, members have a clearer idea of how difficult conversations should happen.

This does not mean everyone will follow every agreement perfectly.

People will make mistakes. Priorities will change. Emergencies will happen.

The value of working agreements comes from having a shared standard that the team can return to.

Reducing Rework and Miscommunication

Clear team working agreements can also reduce avoidable rework.

Suppose a team agrees that every user story must have clear acceptance criteriabefore development begins. A developer then has a better idea of what needs to be built.

Similarly, if a team agrees that code needs a peer review before it is merged, everyone knows the expected process.

These agreements do not solve every delivery problem. They simply remove some common sources of confusion.

Teams may also find it useful to understand thePros And Cons Of Agile Workingbefore deciding which Agile practices fit their situation.

What to Cover in Working Agreements?

There is no fixed list that every team must follow. The best working agreements focus on the areas that matter most to the team.

Core Hours and Availability

Begin with simple availability.

This is particularly important for team members who work flexible schedules or in different locations.

Examples include:

• We will be available during agreed core hours.
• We will update our status when we are unavailable for an extended period.
• We will inform the team before planned time away.
• We will not expect replies outside agreed working hours unless something is genuinely urgent.

The aim is not to track people. It is to make availability easier to understand.

Communication Channels and Response Times

Teams often use several communication tools. Without an agreement, people may not know where to post something.

A simple agreement might say:

• Use the team channel for general updates.
• Use direct messages for private matters.
• Use the agreed urgent channel for production issues.
• Respond to normal team messages within one working day.

Response times should be realistic. Do not create an agreement that expects everyone to reply instantly.

Meeting and Ceremony Etiquette

Meetings can take up a large part of a team's day.

Useful meeting-related agreements include:

• Join meetings on time.
• Come prepared.
• Keep discussions focused.
• Avoid unnecessary side conversations.
• Give everyone a chance to speak.
• End meetings when the agreed time is reached.
• Share decisions after important discussions.

For Agile teams, this may be Daily meetings, Sprint Planning, Sprint Reviews, Retrospective or other team meetings.

Definition of Ready and Definition of Done

Teams can also create agreements around the quality of work entering and leaving their workflow.

A Definition of Readymay state what information a user story should have before development begins.

A Definition of Donedescribes what needs to be done for work to be considered done.

For example, the team could agree that done work should have:

• Development required completed
• Peer review
• Tests carried out
• Resolved known issues
• Met criteria for acceptance
• Updated documentation where necessary

These agreements can help set expectations for both technical and non-technical team members.

Code, Quality, and Review Practices

Technical teams often need agreements around quality.

Possible working agreement examples include:

• Every production code change requires review.
• Reviews should focus on the work, not the person.
• Critical defects should be discussed immediately.
• Automated tests should run before merging where applicable.
• Technical concerns should be raised early.

The exact rules should match the team's work. A small team does not need a huge quality handbook disguised as working agreements.

Decision-Making and Escalation

Teams should also decide how they will handle disagreements and problems.

For example:

• Discuss disagreements directly with the people involved.
• Use facts and evidence to make technical decisions.
• Record important decisions.
• Raise an issue when the team has not been able to solve it within an agreed time.
• Do not ignore a blocker that can affect delivery.

These agreements can make difficult situations less personal because the team already has a process to follow.

Examples of Working Agreements

Looking at working agreements examples can make the idea easier to understand.

Communication and Availability Examples

Here are some simple examples:

• We respond to normal messages within one working day.
• We mark urgent messages clearly.
• We tell the team when we will be unavailable.
• We use shared channels for information that the whole team may need.
• We ask for help when we are blocked.
• We avoid sending non-urgent messages outside working hours.

These are useful starting points, not rules that every team must copy.

Meeting and Ceremony Examples

A team could agree to:

• Start meetings on time.
• Review the agenda before the meeting.
• Avoid interrupting someone who is speaking.
• Keep daily meetings focused on coordination.
• Bring unresolved issues into a separate discussion when needed.
• Finish meetings on time.
• Record important decisions.

The team should keep only the agreements that solve real problems.

Quality and Delivery Examples

Possible agreements include:

• No work is marked done without meeting the Definition of Done.
• Code reviews happen before merging.
• Blockers are raised as soon as they are known.
• Acceptance criteria are checked before closing a story.
• Defects that affect delivery are discussed immediately.
• Team members help one another when work becomes overloaded.

Remote and Hybrid Working Examples

Remote work adds another layer to team communication.

Some remote team working agreements could be:

• Keep your calendar updated.
• Add important decisions to a shared space.
• Mention when you are stepping away for a longer period.
• Use video when it helps the discussion, not simply because it is required.
• Avoid scheduling meetings across agreed focus hours.
• Document information that remote members may miss.

These working agreements for remote teams can help reduce the gap between people working in different places.

How to Create Working Agreements Step by Step?

Knowing how to create working agreements is just as important as knowing what they are.

The process does not have to take an entire day. A focused workshop can be enough for a team to create a useful first version.

Step 1: Facilitate a Working Agreements Workshop

Bring the whole team together.

The facilitator might begin by asking a simple question:

"What do we need from each other to work well together?"

Allow everybody a few minutes to write down ideas.

Get them to think about communication, meetings, availability, quality, decision-making, and support.

A Scrum Master can facilitate this session, but the agreements should belong to the team.

Step 2: Brainstorm and Group Proposals

After all ideas have been shared, group similar suggestions.

Like this:

Reply to important messages promptly.

Respond to urgent requests within two hours.

“Let people know if it’s urgent.”

These may all belong under communication.

Look for repeated themes and remove ideas that are not useful.

The goal is not to create as many rules as possible. The goal is to identify the few behaviours that will make the team's work easier.

Step 3: Agree by Consent and Keep It Short

Discuss each important agreement.

The team does not necessarily need complete agreement in the sense that everyone thinks the rule is perfect. What matters is that members can support it and work with it.

Keep the final list short.

A team with 40 working agreements is unlikely to remember them. A list of 8 to 15 practical agreements is easier to use.

A working agreements template can help with structure, but the content should come from the team.

A basic team working agreement template may include:

Communication: How do we communicate?

Availability: When can people expect us to be available?

Meetings: How will we run meetings?

Quality: What standards do we follow?

Decisions: How will we make and record decisions?

Conflict: How will we handle disagreements?

Step 4: Make Them Visible and Living

Do not put the agreements in a document that nobody opens again.

Keep them somewhere the team can easily see them.

The agreements should also be treated as a living document.

As the team changes, its needs may change too.

A new member may join. The team may become remote. A new product may bring different quality needs. The team may notice that an agreement is no longer useful.

That is a good reason to review the list.

Working Agreements Example (Worked)

Imagine a six-person product team working on a mobile application.

The team has noticed three problems. Messages are sometimes missed, meetings run over time, and code reviews happen too late.

During a workshop, the team discusses what would help.

After the discussion, it creates these agreements:

1. We use the team channel for information that everyone needs.
2. We clearly mark urgent requests.
3. We acknowledge urgent messages within two working hours.
4. We start Agile ceremonies on time.
5. We keep daily meetings focused on coordination.
6. We raise blockers as soon as we identify them.
7. Code reviews happen before changes are merged.
8. We discuss disagreements directly and respectfully.
9. We update the team when we will be unavailable for a long period.
10. We review these agreements during every fourth retrospective.

Notice that these are specific enough to guide behaviour without becoming a huge rulebook.

This is what useful working agreement examples for teams should look like. They should solve real problems rather than sound impressive.

How to Keep Working Agreements Effective?

Creating working agreements is only the beginning.

The team needs to use them and check whether they are still helping.

Reviewing Them in Retrospectives

Asprint retrospective is a natural place to review team working agreements.

The Scrum Master or facilitator can ask:

• Which agreement helped us recently?
• Which agreement did we struggle to follow?
• Is any agreement no longer useful?
• Do we need a new agreement?
• Are we expecting something from one another that is not written down?

This keeps the agreements connected to real team behaviour.

Do not review every agreement in detail every time. Focus on the ones that matter.

Handling Agreements That Are Not Followed

People will sometimes break an agreement.

That does not automatically mean the agreement has failed.

First, understand what happened.

Maybe the agreement was unclear. Maybe the situation was unusual. Maybe the team agreed to something that was not realistic.

The response should be a conversation rather than blame.

Rather than saying, “You broke the rule again,” a teammate might say, “We agreed to raise blockers early. What was difficult this time?”

This approach keeps people accountable, but protects trust.

Working Agreements in Distributed Teams

Having team agreements is even more important when working remotely.

When people share an office, they get information from the informal exchanges, the body language, the quick chats. Distributed teams do not always have those opportunities.

That is why working agreements for remote teams should pay attention to communication and documentation, in line with provenAgile remote working practices. 

Extra Agreements for Remote and Hybrid Work

A remote team may agree to:

• Document decisions after important meetings.
• Keep shared calendars updated.
• Respect time-zone differences.
• Avoid unnecessary meetings.
• Use asynchronous updates where a live meeting isn't needed.
• Clearly state where a response is needed.
• Share context instead of assuming everyone has the same information.
• Protect agreed focus time.

Hybrid teams may need another agreement: make sure important discussions do not happen only between people sitting in the same office.

This helps remote members stay included.

The Scrum Master's Role in Working Agreements

A Scrum Master can play an important role in creating healthy working agreements, but as aservant leader, they should not simply hand the team a list of rules.

The Scrum Master's job is to support the process.

They can facilitate the initial workshop, ask useful questions, spot repeated team problems, and help the group discuss difficult topics.

They can also remind the team about its own agreements during daily work.

For example, if the team agreed to raise blockers early but repeatedly discovers blockers near the end of a Sprint, the Scrum Master can bring this pattern into the retrospective.

The Scrum Master should also avoid becoming the "rule police."

Working agreements belong to the team, which is what makesself-organizing teams work. The Scrum Master helps the team inspect and improve how it works.

SAFe Scrum Master Certification Trainingcan also provide a wider perspective on the role of Scrum Master in an Agile environment for professionals who want to grow their Scrum skills.

Common Mistakes and Best Practices

Working agreements can become meaningless when teams create them just because they are expected to.

Here are some common mistakes to avoid.

Making the list too long

A long list is hard to remember. Focus on the behaviours that matter most.

Creating rules without the team

If one person makes all the agreements, then the team might see them as management rules, not as shared commitments.

Using vague language

"Communicate well" is difficult to measure or understand. "Raise blockers as soon as they are known" is clearer.

Trying to control everything

Working agreements should not dictate every small action. Give people room to use their judgment.

Never reviewing the agreements

A team changes over time. Agreements should change too.

Using them to blame people

The purpose is to improve teamwork, not create a list of reasons to criticise someone.

Copying another team's agreements

A list found online can give you ideas, but it should not replace a team discussion.

The best agile working agreements are simple, visible, realistic, and created around actual team needs.

Conclusion

Working agreements give teams a simple way to decide how they want to work together.

They can cover communication, availability, meetings, quality, decisions, conflict, and delivery. For Agile teams, they can make expectations clearer and reduce some of the small misunderstandings that slow work down.

The best working agreements are not created by one person and forced on everyone else. The team creates them together, agrees to them, uses them, and changes them when needed.

Start small. Pick the areas where your team has the most confusion. Turn those expectations into clear statements. Keep the final list short and visible.

Over time, these small pledges may evolve into strong team norms that encourage improved communication, trust, and accountability.