Scrum Authority Mapping, Scrum Authority Maps, Authority Maps, Scrum Roles, Dan Mezick

Authority issues are at the root of most failed Scrum implementations. Most organizations doing Scrum are unaware of the way Scrum roles contain specific authorized tasks. In Scrum, there is a clear separation of non-overlapping powers across the 3 roles. When this clear division becomes fuzzy, the result is all sorts of serious problems with Scrum.

Diagramming the specific authorized tasks in Scrum, by role, provides a simple and powerful way to depict exactly what is going on with authority in your Scrum implementation. I formulated Authority Mapping in late 2010 in response to client requests for diagrams describing complex authority problems in Scrum.

Freely downloadable Scrum Authority Map diagrams appear at the end of this post in PDF format.

Scrum Authorized Tasks-- by Role

Listing the various tasks authorized under each Role is Scrum an interesting exercise in deconstructing Scrum.

Let's enumerate the specific authorized tasks associated with each Scrum role:

Product Owner: Authorized Tasks

Gather requirements and describe in PB

Define per-story acceptance criteria and “definition of done” as part of requirements

Gather estimates and place into Product Backlog

Prioritize and properly size Product Backlog items

Present PB at Sprint Planning meeting

Preside in authority at the Sprint Planning meeting

Behave in conformance with Scrum rules at all Scrum ceremonies

Optionally abort the Sprint

Accept or reject the increment per definition of DONE

Develop Release Backlog & Plans

Preside in authority at the Sprint Demo

Participate in the iteration retro

Abort the Sprint

Team: Authorized Tasks

Supply estimates to PO for PB items

Pull work (the “what”) from PB to SB during SP meeting

Carve SB into tasks (the “how”) during Sprint

Execute Daily Scrum meeting per Scrum rules

Update the Burndown Chart daily

Deliver per-Sprint increments

Demo increments at Sprint Review

Participate in iteration Retro

Scrum Master: Authorized Tasks

Facilitate Sprint Planning meeting for PO

Facilitate Sprint Review (demo) meeting for PO

Facilitate Sprint Review (retro) for Scrum Team

Facilitate Daily Scrum (each day) for Team

Protect Team from distractions and threats

Referee the rules of Scrum (keep the process)

Identify and remove impediments for Team

Arrange for Daily Scrum (location and time)

Help identify a Product Owner

Authorized Tasks

I do not believe a list of this sort has ever been assembled as a way to analyze and view Scrum along the lines of authorized tasks.

Scrum's clear roles are actually containers that contain authorized tasks-- tasks which that each specific role has the right to do per genuine and authentic Scrum per the Scrum Guide.

It is useful to note that there is little or no overlap in the powers ("authority", or "right to do work") assigned to each Role. Early versions of Scrum vested the Product Owner AND the Team with the dual authority to kill the Sprint. The modern and most current version of Scrum per the Scrum Guide (found at Scrum.org) now assigns that authority ONLY to the Product Owner.

Mapping Authorized Tasks

The clear containment of specific authorized tasks by Role in Scrum creates an opportunity to visually depict or map the Role. This can be done by utilizing a simple "radar" graph, where each 'spoke' in the diagram depicts a specific authorized task for the role under consideration.

For example, here is the initial Scrum Authority Map for the [Team] role:

Figure 1: The Scrum Team Authority Map: Team tasks mapped to a radar graph

With this map, we can now depict the various ways in which a Team can take up (or not fully take up) the Team role. The map provides a way for you to accurately depict what is going on.

In your organization, you are probably familiar with people who "over-step" their Role. They take up more authority than the Role requires. Over-stepping is a common occurrence. Just as common is "under-stepping"-- that is, NOT taking up all the authority vested in a Role.

This is exactly what new Scrum teams do: they under-step, and do not take up the full authority Scrum provides to the Team.

Now here is an authority map, filled in to depict the typical NEW Scrum team:

Figure 2. The Authority Map of a new Scrum Team who is not "taking up" all of the task authority granted to them in Scrum.

Here the new Scrum team is at about 50% on all the tasks they are authorized to do. This means they are assuming only about 1/2 of the authority they have per the Scrum rules. This is typical and entirely normal for new Teams, who often are uncomfortable (at least initially) with the higher levels of authorization granted by Scrum.

The green color signifies the level of authority they have effectively taken up, the yellow region depicts the substantial additional authority they have yet to "take up". Teams new to Scrum typically "under-step" for many complex reasons.

Authority is not something that lays there unclaimed for very long. I'm sure you have seen persons in your own organization that actively collect authority "scraps" and begin wielding these small chunks of authority. When enough authority scraps are collected, they can be combined and converted into a power source. This pattern is a common one in typical organizations.

Authority is often ceded, abandoned or otherwise left behind. Since authorization is valuable, others "take it up". This is exactly what happens to new Scrum teams who are not sure how much authorization they actually have. The authority to do things gets picked up by others-- such as the Scrum Master or the Product Owner.

For example, if the team is timid about pulling work from the Product Backlog during Sprint Planning, the Product Owner or the Scrum Master might choose to "help" by actually assigning the work into the Sprint Backlog (often implicitly) before or during the Sprint Planning meeting. Once that happens, the Team is blocked, demoralized-- and de-authorized.They check out and become a de-authorized team of zombies-- a zombie team-- "present in body only", not engaged and definitely not passionate about this de-authorized brand of "Scrum".

Depicting an Impeded Team with an Authority Map

Here is how a BLOCKED team might look-- a Team who was slow to take up their full Role, and has in fact left authority on the table. But here, the Scrum Master or Product Owner (or someone else) stepped in-- abd actually has picked up all of that authority the Team was slow to take up:

Figure 3. A Team with authorization blockages depicted.

Here, red signifies that some other person, group or organization is effectively impeding the Team from fully taking up all the authority genuine Scrum provides. In this depiction, the Team is 'surrounded' by others who are taking up about 50% of their total authority per Scrum.

The others might be people that are NOT the Scrum Master or the Product Owner. The blockage might be systemic and a function of the culture. The main advantage of the Authority Map is that it depicts what is actually going on with the Team authority.

In real-life scenarios, the Authority Map for the Team has an endless variety of odd shapes that vary according to the situation. Some patterns are typical and others are less common. The pattern above is a simple illustration.

The Artful Scrum Master

Teams typically are slow to take up the full authority granted by Scrum. There are many reasons for this. They might not want the higher levels of authorization Scrum provides. The new Team role with higher authorization might not be comfortable. The team might want to told what they "should" do. Or the Team may have low confidence that the organization is capable of actually maintaining high levels of Team authorization.

Eventually, if the organization is genuinely committed to Scrum, the Team will begin to take up the full authority vested in them by Scrum itself. It is the job of an artful Scrum Master to MAKE SURE that others do not "take up" the Team's task authority during this delay. This is part of what is ment by the phrase "Protect the Team".

If you have an artful Scrum Master, then within 2 or so iterations, the Team will begin to put its toe in the water, testing to see if they really do have the power to load the Sprint Backlog, define the Tasks, conduct the Daily Scrum and so on. When they realize they do, their Authority Map looks like this, the Authority Map profile of a healthy Scrum Team:

Figure 4. A healthy Scrum Team who fully "takes up" all the authority granted by Scrum.

Authority Mapping is a simple yet powerful way to depict exactly what is going on with authority in Scrum-- by Role. Similiar maps can be created for the Product Owner and Scrum Master role. An endless variety of situations can be depicted accurately using the Authority Map technique.

Practical Use of Authority Maps

Authority Maps are useful for depicting authority-related impediments, and provide a visual context for examining the problem under consideration. These maps are particularly useful for depicting issues with Scrum to sponsors, executives and Product Owners, as well as Teams.

Use of Authority Maps is especially useful for Scrum Masters during Retrospectives with the Scrum Team. These diagrams are also useful at the start of adopting Scrum, to help describe and depict the various ways sponsors and executives can help Scrum take root. For example, a depiction of the Team's Authority Map before and after an executive attends a Daily Scrum as an Observer can be useful for habituating those executives to Scrum and Scrum dynamics

Summary

Explicit examination is a hallmark of genuine and authentic Scrum. Authority maps extend our ability to visualize social dynamics in an easy-to-read yet powerful depiction of the current reality of our 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.

Next Part: Click here for the NEXT PART in this series

Links:

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 InfoQ.com, ScrumAlliance.org, and AgileJournal.com. 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 InfoQ.com

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