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

This is a Agile coaching case study example depicted with Scrum Authority Mapping. This is Part 3 in the introduction to Scrum Authority Maps. In this situation, the PO and the SM are engaging is some very clear over-stepping of authority. Each of them is taking up authorized tasks that belong the the team. As a result the Team has no sense of control and is demoralized.

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

Getting Oriented

Use these links if you are new to the concept of Scrum Authority Mapping:

Scrum Authority Mapping Introduction

Scrum Authority Mapping Part 2

Red: depicts authority that belongs to the Team, that the Team has ceded to others, or others have taken up. With Authority Maps, you want to 'get the red out'.

Yellow: depicts authority the team has ye to to take up, that actually belongs to them

Green: depicts the authority the team is granted per Scrum, and has actually taken up so far. A healthy map has lots of green, very little yellow, and no red.

Labels depict who is doing what. Labels are typically places over the red regions.



This essay uses these abbreviations:

PB: Product Backlog

SB: Sprint backlog

SM: Scrum Master

PO: Product Owner

SP:Sprint Planning

DS:Daily Scrum

SD:Sprint Demo

SR: Sprint Retro



Without knowing anything at all about the deatils , you can derive the following immediately from this map:

1. The PO is meddling with the SB, pulling work from the PB into the SB using the SP meeting.

2. the PO is meddling in the Teams's job of carving the user stories in the SB into tasks.

3. The SM is updating the BDC.

4. The Team is not blocked on the tasks depicted in yellow, but for some reason they are slow to take up these tasks fully. These tasks include supplying estimates, participating the retro, doing the demo, delivering the increment, and executing the Daily Scrum

The Story on this Team

This is an actualcase study from my Agile coaching work in 2010. When I stepped in, the PO was literally pulling the work from the PB to the SB during the SP meeting. Also during this meeting, the PO would ask the Team for estimates. There were no estimates on the PB in advance of the SP meeting. The Team would be asked in public during the SP meeting to supply estimates.

After the SP meeting was over, the Team would convene to break up the user stories in the SB into tasks. These tasks would be placed on index cards and taped to the wall beneath the user story. A sticker indicating "not done" would be placed on the task-card. When this was all set, the Team started working.

When a task was "done", it was not quite done-in-fact. For most "done" tasks, the Team had to wait for the PO to check it out during the Sprint. If the PO thought the task was done, she would place a 'done' sticker on the card.

There was an "Agile coach" who was helping with this Team. The coach was there in an "embedded" mode, literally functioning as the SM. One other fact is interesting to note: as SM, this "Coach" would update the Burn-Down chart.

Primary Problems

Only the Team has authority to populate the SB in Scrum, during the SP meeting. (Define the "WHAT"). Here the PO is doing it "for" the Team.

Only the Team has authority to carve up the stories into tasks. (Define the "HOW"). Here the PO is "helping" with that. Further, the definition of done is subjective and based on how the PO feels, as indicated by examining each task and declaring it done item-by-item in side the Sprint.

Only the Team is authorized to update the BD chart. Here the SM is doing that "for" them. Add to this the fact the person is SM mode is a "Coach". No one is learning the SM role by watching and by doing; the 'Coach" owns the SM role. That in itself is a HUGE problem, do you see why?

Add to this the fact that the SM is doing a taks that ONLY the Team is authorized to do, and you can see the level of distortion in this Scrum situation.

Secondary Problems

The BD chart for this Team was often a straight diaginal line, like this:

Figure 1. Burn Down Chart Diagonal Shape.

This makes total sense when the Team is being asked for estimates on demand at the Sprint Planning meeting. They offer estimates that they are sure to be able to deliver on, and then manage the BD chart throughout the Sprint. Normal BD charts are seldom in the shape of idealized diagonal lines. The diagonal BD chart is a tip-off that somthing is up.

The Team is not doing all the tasks to the full extent they are authorized. This is depicted in yellow and the tasks that have this status are: supplying estimates, participating the retro, doing the demo, delivering the increment, and executing the Daily Scrum. These tasks are weakly taken up because the Team has a very low level of perceived control. They are in fact dominated by the SM and PO. The Daily Scrum for this Team was also interesting since the PO attended it, and often interjected with questions as Team members recited. As you might expect, the individual team members often recited to the PO, rather than to each other.In addition the PO often prompted teh next person in sequence to recite, using non-verbals (eye contact) to signal who was next.

Moral of the Story

Scrum authorizes specific tasks for the Team, PO and SM. There is purposely almost no overlap for authorized tasks by Role in Scrum. Sticking within these authority boundaries is the hallmark of great Scrum. Here we have the SM and the PO doing essential tasks that only the Team is authorized to do. The result is a Team dominated by the PO and SM. This Team is not strong in the aspects of their role. This makes total sense since they have a very low level sense of control over their work.

Moral of story: There are many ways to screw up a good opportunity to do great Scrum. A competent Scrum Master is a necessity, both for calling out problems and making sure the Team is protected as they move to fully take up their tasks.

The Authority mapping technique provides a powerful Agile information radiator that conveys the essentials of authority dynamics by role, in a compact, information-rich diagram.


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.

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

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


Date of note: 1/9/2011

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 Mezick 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