Work Agreements for a Scrum Team

22 January 2014

Vignesh Murthy
Arrk Solutions Pvt Ltd

Work agreements are the set of rules/disciplines/processes the team agrees to follow without fail to make themselves more efficient and successful.

Who sets the work agreements?

Team members themselves set these. The ScrumMaster may have to play the role of facilitating the meeting that's held to come up with work agreements, but it is the team that decides on the agreements themselves. The team also reviews them periodically during retrospective meetings.

What is the best time to organize this meeting?

We did this in our retrospective meetings. These can also be separate meetings by themselves.

What do you need for this meeting?

  • All team members.
  • Whiteboard
  • Marker

How do we come up with our first set of work agreements?

The ScrumMaster kicks off the meeting by explaining to the team what a work agreement is (as mentioned above) and then shares some examples of work agreements to give them a fair idea. For example: "Update the status on the Scrum board regularly." "Be on time for the stand-up." And so on -- they could be any items the team thinks are crucial for their success or improvement. The ScrumMaster then suggests to the team that they brainstorm the points that are crucial for their improvement and asks them to share the points they think should become work agreements.

Team members share their suggestions and the reasons why they think those should be work agreements. Some of the points could be relatively straightforward. The ScrumMaster takes note of these ideas on the board.

After the brainstorming session, the ScrumMaster informs the team that they should pick the top five ideas as work agreements, based on voting. It's a good idea to give each team member three or five votes and ask them to vote for the agreements on the board that they think are crucial.

After the voting, the ScrumMaster counts the votes and shares the top five agreements with team. The team should reiterate that these are the agreements that they have consented to follow in order to be a successful team, and they should always adhere to them. If any team member does not adhere to one of the agreements, other team members should remind him or her.

These five agreements should be put up on display in the team's shared space.

Maintaining the work agreements

Work agreements should be reviewed at the end of every sprint during the retrospective meeting. Once team members feel they are doing well on one agreement, they can replace it with another agreement to focus on.

My experience

This system has worked really well for my team.

There are a couple of work agreements, specific to our team, that have worked especially well: "Don't commit to unknown stories" and "Review the JIRA board daily and set a focus for each day." Since we are a distributed team, we have a stand-up in the afternoon, when the onshore team from the U.K. is in their office. The team came up with this agreement to review the board in the morning and communicate what they will be working on. This has worked wonders; a lot of communication happens in this meeting, and I can see teamwork in the managing of the sprint scope.

Other work agreements are: "Documentation for critical tasks" (the team plans it as subtask during planning wherever applicable) and "Identify dependencies" (they identify dependencies in an early stage and document them on tickets, either during look-ahead meetings or planning meetings).

Let me know your views. Thanks.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.1 (9 ratings)


Michael Kuesters, CSP,CSM,CSPO, 1/22/2014 2:29:46 AM
Each team has Working Agreements.

The two most cruicial WA's I have found are the DoD and the DoR.

It is very easy for new teams to come up with hundreds of sensible WA's, but people will soon realize that this, in itself, is not sensible - because nobody can honestly claim to remember that many: so teams usually go trashing most of them in due time.

I like your idea of taking the Top 5 WA's and posting them on a shared space for everyone to behold.
Vignesh Murthy, CSM, 1/22/2014 2:43:24 AM
Thanks Michael,

I feel DOD (definition of done) is something like a checklist to ensure before closing the story whereas work agreements are the consensus amongst team members to be on same page when it comes to ways of working. This has worked for me so far and I have been getting positive inputs while re-visiting the WA's in every retrospective. Top 5 Worked for us so far :)

DoR (Definition of Ready) is taken care by PO in our case.

Cheers, Vignesh
Michael Kuesters, CSP,CSM,CSPO, 1/22/2014 2:58:21 AM
This gets philosophical, but what is a WA really? It's a mutual agreement "This is how we do things" - and both the DoR and DoD also need to be agreed among the team, and as you said, if someone does not keep these, others need to remind them.

I would modify your sentence about the DoR: The DoR should be warranted by the PO, but everyone on the team should have a mutual understanding of what "Ready" means.
Kamal Hasan Kotapati, CSM, 1/22/2014 10:23:47 PM
I strongly feel that the work agreement document should have DOR and DOD (key/common points). Also, it should be updated as and when any action points (Process improvements) made during sprint retrospective meeting. It is not necessary that we have to stick to 5 agreements/points and it depends on the scrum team
Randall Schmidt, CSP,CSM, 1/23/2014 5:25:26 AM
Sorry folks, sounds entirely too waterfall-ish or the rigors of Project Management to me. With all these documents and expectations - how many of them are helping the team determine its own self management?
the journey should be FUN!
Vignesh Murthy, CSM, 1/23/2014 5:50:48 AM
Thanks Kamal - I agree every scrum team should have DOD & DOR which are directly linked to how me manage the stories. We do have these definitions and are using it for what they are intended to.

The WA I'm referring is something that goes beyond Stories. As Michael mentioned in his previous comment team can come with 100 WA, but having TOP 5 (or 3, as little possible) agreements makes sure team is focussed on it.

Through this article I'm sharing my experience as it worked for our team. To be clear, this is not a document, it is set of 5 one liner agreements. I wish I could share the picture of the team shared space where we have put up these 5 points on board.

Thanks for your opinion Gents :)
Michael Kuesters, CSP,CSM,CSPO, 1/27/2014 12:25:29 AM
Randall, I would like to contradict you a bit on that.
Defining WA's, prioritizing them and sticking them on a visible board is not "waterfall-ish".

As I personally like to say, Agile succes doesn't come from throwing all previous management practices overboard, but from high motivation, high engagement and high discipline - combined with hard work.
That's not saying that work can't be fun, but creating WA's which nobody takes seriously are the perfect road to failure, since it devoids the term itself of meaning.

I noticed myself that the visible WA's tend to create significantly more discussion "Why are we doing the story like this? Is our current way really in line with our WA's? Do we even need this WA? Should we modify or even abolish it?" - while "invisible WA's" only linger and get pulled out only on occasion to clubber someone over the head with.

To obtain living and strongly observed WA's, I think leaning out the list of WA's and focussing really is a good way. This will actually get the team to become self-managing in the first place.

It will become obsolete once the team is in hyper-performance mode, but let's be honest: how many teams are "there" yet?
Phillip Stiby, CSM, 1/28/2014 4:06:36 AM
hmmmm, getting a little dogmatic but..
"Individuals and interactions over processes and tools" - Agile Manifesto

This scream more process and tools over individuals and interactions.

Likewise this seems to double up on the purpose of the retrospective which is to look back at the good and the bad and for the team to adapt and improve based on there experience.

Now don't get me wrong I see lots of teams creating lists of good and bad points and then create a list of changes to make in the next sprint.

However change is something that should be targeted and done in small increments. So I would always suggest a team group there good and bad points and choose the three largest and make a small number of improvements.
Karina Bernacki, CSM, 2/9/2014 8:04:25 PM
I can appreciate this post and your intentions behind sharing this message. I am a SM for two teams and one of them in particular has been struggling a bit with the self-managing aspect of their new world. In the last retro some internal team issues arose which highlighted the team's need to build a set of working agreements and shared values.

The working agreements, in my mind, do not have to represent a checklist and do not have to tie back to the product. They can be sustainable agreements that help the team identify core values and build a shared understanding of what it means to work as a team.

Imagine a scenario where an individual on the team is not contributing or is routinely absent from the daily stand-up. In the old command and control days the person's manager could be notified to handle the situation. In a self-managing team within a flat org it is now up to the team to handle such issues. When you are dealing with new teams this can feel like a very heavy burden and the intimidation of handling such issues often leads to them being ignored or avoided to the determent of the entire team.

Openly discussing what everyone agrees makes a 'good' team member, and developing shared expectations helps teams openly address these types of issues. I have even seen some teams institute some silly penalties for breaking agreements, such as jumping jacks, or singing a silly song for being late to the daily stand-up.

As with most things I encourage my team to implement things such as these if and when they need them. In my situation this team is seeking a way to openly discuss and illustrate what they expect from one another, and to build a stronger sense of accountability to the team as a whole.

Thank you for your post.
Vignesh Murthy, CSM, 2/11/2014 11:01:16 AM
Thanks Karina,

You nailed it here :

The working agreements, in my mind, do not have to represent a checklist and do not have to tie back to the product. They can be sustainable agreements that help the team identify core values and build a shared understanding of what it means to work as a team.
Gurpreet Singh, CSP,CSM, 5/11/2014 6:11:27 PM
Hello all,

Allow me to put more spice to this discussion! What I feel is that we still need some sort of Identifiers to gauge if we (team) is sailing in the right direction.

What I personally feel that the User Acceptance Criteria, Definition of Done, Key Performance Indicators (KPI), Definition of Ready, Business As Usuals,etc should go hand-in-hand.

I have felt quite a times that the Definition of Done was completely out of Sync with the KPI (product vision's checklist) and the PO/ Stakeholders just assumed that the team is aware of the Business As Usuals (like common sense) as they (the stakeholders) think! The difference in the 'assumed' definitions cause a lot of discomfort!

Still said and done: Minimal count of these indicators should be used (not all) matching the Team' structure, Organization's Culture and Projects' needs.

Lastly, the entire Team should be put into the loop to decide which of these indicators go well with the Product's success!

You must Login or Signup to comment.