Scrum Authority Mapping, Scrum Authority Maps, Authority Maps, Scrum Roles, Dan Mezick
Agile Boston, Agile MA, Agile training Boston, Agile training MA Agile Boston
Phone: 203-234-1404  Email:
Home About Prev.Meetings Next.Meeting DirectionsRSVP Schedule SponsorInfo AgileLinks Contact

Original date of note: 1/1/2011

Click here to return to the Agile Boston home page

Click here to return to the Agile CT home page

NOTE: if you are new to Scrum Authority Maps, please see Part1 of Scrum Authority mapping.

Depicting an Ineffective Scrum Master in an Authority Map

The situation described above is coming directly from my experience coaching Agile teams. The story is complex and is a good example of how Scrum Authority mapping can help illustrate exactly what is going on in a Scrum implementation. The previous essay introduced Authority Maps and depicted some very basic concepts using the Team role. This post jumps to more advanced concepts, introduces some new Authority map features, and focuses on the Scrum Master role.

The Authority Map diagram above depicts a case study from my work coaching an Agile team of twelve. The team was self-managed with the purpose to develop an information system. The team included the following product development disciplines: customer relations, requirements development, design, test, integration, documentation, product release, and support.

This Authority Map introduces some new elements.

Labels: The labels 'Product Owner' and 'Team Member' in the diagram depict who is blocking. Labels only appear in red regions.

Regions: Since social complexity has endless variation, so do Authority Maps. They can map ANY Scrum situation by Role. In this diagram, a 'region' to the right side is depicted for 'Protect the Team'. The region is bounded by lines drawn into the map. In this example the region, in red, is around the 'Protect the Team' task and it is labeled. The bounded region is labeled, and is in red, showing who is blocking what Scrum Master task.

The Story Behind the Diagram

The story on this Scrum Master Authority Map is as follows: The team is a team of contractors, selected by the PO. The Scrum Master is also a contractor, selected by the Product Owner. The Product Owner is already in place, and so is the Daily Scrum meeting time.

The Product Owner Blocking- in Red

The Product Owner (PO) set up the recurring schedule for the Daily Scrum before this Scrum Master arrived on the scene. Thus the tasks of "Help Identify a Product Owner" and "Arrange for Daily Scrum" are depicted in red as regions to the left of the diagram, and labeled "Product Owner".

A Team Member Blocking- in Red

One of the Team members has taken up the "protect the team" task that actually belongs to the Scrum Master (SM) per the rules of Scrum. This situation developed with the implicit approval of the PO, and in advance of this SM arriving on the scene. As you can see, the SM is in a no-win situation. Three of his primary tasks are taken up by others.

What is the Scrum Master thinking?

As you can see, this SM is very ineffective as illustrated by the very low percentage of green color in his Authority Map. What's up here?

The larger concern for this SM is that the Team Member doing "Protect the Team" demonstrates total authority over the "Protect the Team" task during the various Scrum meetings. The Team member rants and rails at the PO openly in Sprint Planning meetings and in other episodes. The Team member is corrected by the PO. The SM, who is a contractor under the authority of the PO, is aware of the corrective action. The SM tries to take up the "Protect the Team" task but he learns that the subversive Team member thwarts him when he tries. So eventually he gives up on that task, acknowledging the Team Member's informal authority over it

All of the above explains the red regions depicted to the left and right of the diagram. Now, what about the yellow areas on this map? Those are depicting authority the Scrum Master is slow to take up.

He is slow to take up these tasks, such as effectively facilitating all the Scrum meetings, because he is demoralized.

He is a contractor protecting his income.

He is hired by the PO and knows the PO at least implicitly approves of the Team member's "Protect the team" behavior.

As a result he is less effective in the other essential tasks for his SM role. He is slow to "take them up" and in fact is never really very effective at any of the Scrum Master's tasks.

The Happy Ending

This is a scenario that happened inside a Scrum implementation. At the appropriate time, the PO explicitly confronted this reality and changed the Team composition. In the new situation the protective Team member is off the Team, and there is a new SM. The result is more health and wellness for the PO, the SM and the Team. The current Authority Map for the current SM has much more green in it, indicating much more effectiveness for both the SM and the Scrum team as a whole.


Authority Maps provide a powerful way to depict graphically what is happening in any Scrum situation.

The graphical depiction augments any verbal description.

Since about 50% of people learn through seeing images and diagrams, Scrum Authority Maps are useful for communicating the often subtle dynamics that emerge in Scrum implementations.


Authority Map Diagrams are Available Now

You can download blank authority maps for the Product Owner, Team and Scrum Master roles below, for use in your own coaching and Scrum Mastering work.


Previous and Next Parts in this Series

Click here for the FIRST PART in this series


Reference: Boundary, Authority, Role and Task: BART Analysis of Complex Systems

Download: PDF document containing Scrum Authority Maps for PO, SM, Team



Click here to examine MORE AGILE NOTES like this

Click here to return to the Agile Boston home page

Click here to return to the Agile CT home page

About the Author

Dan Mezick: An expert on teams and a trusted adviser to CxO-level executives worldwide, Dan consults on enterprise-wide culture change, implementing Scrum, and the often difficult adoption of authentic Lean principles. Learn more about Dan Mezick here.

He creates and teaches specific, useful tools and techniques for facilitating successful enterprise-wide adoption of agile and Scrum. Dan’s articles on teams and organizational dynamics appear on,, and Learn more about Dan Mezick's agile writing here.

He's the organizer of the Agile Boston user group and a 3-time presenter at Agile2007, 2008 and 2009, an invited speaker to the Scrum Gathering (Orlando) in 2010 and a news reporter for

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

You can learn much more detail about Dan via his Agile Coaching page here.

Click here to examine MORE AGILE NOTES like this