The importance of team working agreements

working agreement templates

A guest post from Fearless Scrum Master Jenny Walter

Working agreements are underrated. Whether standing up a new team, transitioning to a new team, or currently working as part of an existing team–you should always have a working agreement. It is one of the very first artifacts that should be created for a team. In agile projects, this is the foundation for how the team will work together.

At the most basic level a working agreement is a set of guidelines that define how groups want to work together, and what they want in the working environment and from each other to feel safe and free to learn, explore and discover.

I am a Scrum Master so I am probably a bit biased when it comes to the benefit of working agreements, but it really helps to align everyone involved. It helps to expose any uncomfortable topics, or pet peeves that some team members might have, while also ensuring that every team member’s voice is heard regarding ‘how’ they like (and want) to work together. It is honest and transparent and something that the team should revisit every couple of sprints.

As the Scrum master, you should definitely revisit it if anything changes within the team (a new member joins or departs, a global pandemic, etc), or if you notice any behavior or activity that seems ‘off’ with the team.

There are two types of working agreements that I like to create. One is internal and it is just for the team. The other is external and it is for the team and the customer. Let’s first explore the internal working agreement.Working agreement template

Working agreement template

  • General/Team Norms

Try to align the team and agree that everyone has good intentions

Opportunity to determine what’s important to the team (being on time, having video on during conference calls, etc)

Sprint ceremonies

  • Detail out the purpose of each ceremony, as your team understands it, and agreement on when each one will happen

User stories and Definition of ‘Done’

  • Determine what user stories mean for your team (How will they be composed? Who will compose them?) and what makes each one ‘done.’


  • How are you going to talk to each other? Does the team hate email? (This is all about what works for the team.)
  • What tools are you using on this project? Does everyone know how to use them (have access to them) and feel like they are equipped for success?


  • How do you know where to be and when?
  • Is there a team calendar? Or will individual meeting invites be sent out?
  • What if someone is on PTO or sick? Will this be put on the calendar or communicated some other way?

For the first working agreement, it is fine to keep it simple. Then as the team starts working, different needs (or challenges) might arise that would warrant a revisit of the working agreement.

Now let’s explore the external working agreement. As previously mentioned, this is the working agreement between the Scrum Team and the external customer. The external working agreement should initially have the same components of the internal one. This will help start the conversation with the customer. It surfaces their expectations of the team and vice versa. It is also helpful to have something to refer back to if any issues arise along the way.

After it’s established, you need to make sure that it’s posted somewhere that the team and customer have access. You also need to make sure that it is revisited so that it can be updated or modified, if needed. I have found that this one usually does not have to be revisited as often as the internal working agreement, but don’t just create it and forget it.

A working agreement can be a very helpful tool to ensure your ScrumTeam and your customer are working together in the best way, and both are getting what they need to be successful.

So if you ever think your team or customer needs realignment, then I would dust off your working agreement (or create one if you do not have one) and bring everyone together for a conversation. It will be worth it!

Hi, we’re Fearless, a full stack digital services firm in Baltimore that builds software with a soul.