Clear Expectations How Working Agreements Help Scrum Teams

Scrum Teams are self managing. This means they decide the best way to accomplish their work. But self management does not mean chaos. It requires structure and shared understanding. Working agreements and team norms provide this structure. They define how the team will operate together. These are not rules imposed from above. They are agreements the team makes for itself. This helps avoid misunderstandings and friction. It builds a foundation for effective collaboration and continuous improvement.

What Are Working Agreements

Working agreements are explicit expectations created and owned by the Scrum Team. They cover how the team will work together, communicate, and resolve disagreements. They are living documents, not set in stone. The team should review and adapt them regularly, especially during the Sprint Retrospective. They make invisible expectations visible. This reduces assumptions and improves team cohesion. Think of them as the team's social contract.

Why Teams Need Them

Without clear agreements, teams often struggle with communication breakdowns or unspoken resentments. A Developer might prefer synchronous communication for urgent issues. Another might prefer asynchronous. If this is not agreed upon, one person feels ignored, the other feels interrupted. Agreements prevent these small issues from becoming large problems. They foster transparency and psychological safety. When everyone knows what to expect, they can focus on delivering value. They support the Scrum Values of commitment, focus, openness, respect, and courage.

Examples of Common Agreements

Working agreements can cover many aspects of team life. They should be specific enough to be useful, but not overly prescriptive. They should address areas where the team has experienced friction or sees potential for improvement. Here are some examples of topics a Scrum Team might agree upon:

• Daily Scrum: When and where it happens, how long it lasts, what is discussed.
• Communication: Preferred channels for urgent versus non-urgent messages, response times.
• Code Reviews: Expected review time, definition of done for a code review.
• Conflict Resolution: Steps to take when disagreements arise, how to escalate if needed.
• Meetings: How to prepare, how to participate, guidelines for focus.
• Breaks: When and how team members communicate they are stepping away.

For instance, a team might agree: 'During the Daily Scrum, each Developer will state what they worked on yesterday, what they will work on today, and any impediments. Keep it to two minutes per person.' Or: 'For urgent issues, use direct chat and tag the relevant person. For non-urgent items, use the team's project management tool.'

Creating and Evolving Agreements

Working agreements are best created collaboratively. The Scrum Master often facilitates this process. It usually happens early in a team's formation or when a new member joins. The Sprint Retrospective is the ideal event for reviewing and adapting them. If an agreement is not working, the team should discuss why and propose changes. This iterative approach ensures the agreements remain relevant and effective. They are a tool for the team's self management, not a static rulebook.

When a team identifies a persistent issue, an agreement can be a direct solution. For example, if team members often miss critical updates, an agreement might be: 'All significant changes to the Sprint Backlog must be communicated in the team's dedicated chat channel.' This provides clarity and a shared understanding of expected behavior. It moves the team toward greater professionalism and effectiveness.

Start with the Foundations module →

Or take the full Scrum Master track →