Scrum Team Accountabilities and responsibilities can be confusing, misunderstood, and lack shared understanding between its members and the organization. This is especially true for new Scrum Team members, yet I also have experienced this with teams who have been using Scrum for several years. And sometimes these misunderstandings are perpetuated by the organization and its leaders. For example, I've seen Project Managers transition to Scrum Masters yet hold on to budgeting and forecasting, assign work to Developers, and provide status reporting to stakeholders. To make matters worse some organizations hold the Scrum Master or Product Owner accountable for many project management activities. Just take a sampling of Scrum Master job postings and you'll see what I mean by this.
In this blog post, I'll share with you an exercise to help make transparent expectations of each Scrum Team member, by driving conversations about what team members already understand and where there are potential misunderstandings that need to be changed. Several years ago an Agile coach ran this exercise for my Scrum Team, and since then I've used it with many teams. I've also adapted this to align with the November 2020 Scrum Guide changes, which replaced roles with accountabilities, and removed Development Team in favor of Developers.
The Scrum Guide no longer mentions Scrum Team roles. Roles have been replaced by accountabilities, meaning to account for one's actions or willingness to accept responsibility. The Scrum Team consists of three accountabilities: Developers, Product Owner, and Scrum Master. These are a minimum set of accountabilities from which a job role or job description can be instantiated from, and many companies will add other accountabilities and responsibilities.
Plan on up to 2 hours for this exercise. Here are the basic steps:
PreWork (10 minutes)
You'll need the Scrum Guide for the pre-work if your team isn't familiar with it or needs a refresher. You can either ask your Scrum Team to read the accountabilities section before the session, or you can spend 10 minutes reading and exploring it together at the beginning of the session. I prefer the latter, which can an eye-opener in itself.
If you are facilitating this in person, make sure to have a whiteboard or flip charts, markers, post-it notes, and some small dots to stick onto a post-it. I used a collaboration tool called Mural for this example.
Step 1 (5 minutes)
Create a 3 X 3 grid with three columns and three rows, and label the columns and rows with the three Scrum accountabilities, as shown below. I suggest putting the Scrum Master accountability in the last column and row (so that you can focus on providing instructions, observing, and answering questions), but this works in any order. I also provide a brief overview of what comes next.
Step 2 (50 minutes)
The next step is to gather some information about your team's understanding of each accountability. Give everyone post-its and stickies. Start with one column at a time, and timebox each column to 15 minutes.
For the first column, ask "What will we hold the Developers accountable for?". Each person, including the Developers, will capture one idea per post-it in silence, and place it in the appropriate row. Hold off on having conversations about what has been gathered, for now. A read-out and conversations will take place in step 3.
For the Developer's column, Developers capture what they think they are accountable for, the Product Owner captures their understanding of what the Developers are accountable for, and then the Scrum Master captures their understanding of what the Developers are accountable for.
Next, the team works on the Product Owner column, and then finally the Scrum Master column. After 50 minutes your accountability board should be filled with post-its, as shown below.
Break (10 minutes)
Since you're just over halfway done, now is a good time to take a coffee break.
Step 3 (30 to 45 minutes)
The final step is time to review each column, one at a time. I timebox each column to 10 minutes. If there are a lot of misunderstandings or you have a large Scrum Team you may need more time. It is important not to rush this step. Look for misunderstanding or incorrect terminology, while showing curiosity and asking open-ended questions. I'll highlight those things in red if I'm using an online tool, or put a red dot on the post-it if I'm facilitating in person.
As an example, in the Developer's column there are two misunderstandings to call out:
- Keeping the Product Owner updated at the "standup". This is a teaching moment to make sure the team understands that the correct term is Daily Scrum, not standup. But more important this is a planning meeting for the Developers to inspect progress towards the Sprint Goal and adapt their plan for the next 24 hours. This is not a status meeting for the Product Owner!
- The Product Owner is accountable for estimation. This is a coaching opportunity to help the team understand that those doing the work (the Developers) are accountable for sizing their own work. A Product Owner does not provide estimates (unless they are also holding a Developer accountability).
After teaching, coaching, and getting consensus from the team I'd remove those post-its from the Product Owner zone.
Where I need to clarify language or move accountabilities because they are in the wrong columns, I will change a post-it to green for updates needed (or use a green dot if in person). Here are some examples to help the team understand proper Scrum terminology:
- The Product Backlog is ordered, not prioritized.
- Rather than the Product Owner being accountable to create the Sprint Goal, that card was changed to help everyone understand that the entire Scrum Team creates the Sprint Goal in Sprint Planning.
- Grooming is no longer a term used - that term was removed many years ago in favor of refinement.
There were also cards that were in the wrong columns, which I color-coded in blue and moved to the correct column. Examples:
- Developers track their own work with a burndown and understand their velocity, not the Scrum Master.
- The Product Owner is accountable to understand dependencies, not a Scrum Master.
Summary
Scrum Team accountabilities and responsibilities can be confusing, misunderstood, and lack shared understanding between its members and the organization. This exercise makes transparent the accountabilities of each team member by driving conversations about what team members agree on and where there are gaps. Use this exercise when new teams are formed, or when you see misunderstandings and knowledge gaps around Scrum Team accountabilities and expectations.
The exercise involves everyone on the team by giving each team member a chance to do some silent writing. It can be run in person with a large whiteboard, flip charts, post-it notes, markers, and small dots. And it can also be adapted to be used with Zoom videoconferencing and an online collaboration tool such as Mural.
Want to learn more effective skills and techniques to improve your facilitation and get everyone involved? Join me for an upcoming Professional Scrum Facilitation Skills™ course.
Professional Scrum Facilitation Skills™
The Professional Scrum Facilitation Skills™ is an interactive course designed to help Scrum Teams and individuals develop proficiency in facilitation skills, learn when and how to select effective techniques for various circumstances, and enable better problem-solving, more effective Scrum events, and greater team alignment, all leading to better outcomes.
⏩ Join Chris Belknap, PST for Scrum.org's NEW Professional Scrum Facilitation Skills™ (PSFS) course to level up your facilitation skills:
