November 24, 2010 Event: The 2nd Annual 2010 GIVE THANKS FOR SCRUM !!

The 2nd Annual 2010 GIVE THANKS FOR SCRUM !!

We had sessions from the tribal elders of the worldwide Scrum community;  none other than JEFF SUTHERLAND and KEN SCHWABER, the formulators of Scrum.

Scrum is not a “process”.  Scrum is not a “methodology”.  Scrum is a FRAMEWORK for manifesting greatness in teams who are building software and complex products.  Attend this annual Scrum community event to learn from Jeff and Ken, advance your Scrum knowledge, and have some fun socializing and making friends.  If you are into Scrum in Boston, this is your tribe !

This popular annual event was brought to you by AgileBoston.

Where:  Microsoft Corp., 201 Jones Rd., Waltham, MA 02451
Date: 11/24/2010
Time: 10:00 AM to 4:30 PM

This year seating was limited to 210 attendees.

2010 Give Thanks for Scrum Audience

Photos are Copyright 2010 Tracy White

GTfS 2010_61.jpg by IT Event Photography BostonGTfS 2010_62.jpg by IT Event Photography BostonGTfS 2010_63.jpg by IT Event Photography BostonGTfS 2010_64.jpg by IT Event Photography BostonGTfS 2010_65.jpg by IT Event Photography BostonGTfS 2010_68.jpg by IT Event Photography BostonGTfS 2010_69.jpg by IT Event Photography BostonGTfS 2010_70.jpg by IT Event Photography BostonGTfS 2010_71.jpg by IT Event Photography Boston

Speakers: Jeff Sutherland, Ken Schwaber and Dan Mezick

Please support our sponsors for the event:



09:30AM Doors open, check in, socialize

10:00PM Dan Mezick on: OPENING REMARKS


11:30PM LUNCH and socializing……….

……………LIVE acoustic guitar music with BOB MAC WILLIAMS,

……………GREAT food,

……………Opt-in, live-demo of RALLY’s software tool for Agile, delivered by a RALLY rep

……………Opt-in, live-demo of VERSIONONE’s software tool for Agile, delivered by a V1 rep

01:00PM Dan on AUTHORITATIVE SCRUM diagnostics

02:15PM Ken Schwaber on SCRUM 2010: THE QUIET REVOLUTION

03:30PM Live QUESTIONS & ANSWERS ON SCRUM with Ken and Jeff

04:30PM Raffle, last-minute socializing, closing remarks

05:00PM DONE!!



Jeff Sutherland

There are endless studies of dysfunctional Scrum and a 1000 ways to implement ScrumBut (We’re doing Scrum, but….) What happens when a company, a coach, or a team aggressively implements Scrum and successfully removes impediments? I’ll discuss three papers presented at Agile 2010 as snapshots of successful Scrum.

The first snapshot is of an artificial life company in Finland where the entire management team got on board with Scrum. The paper is on how the managers felt after a company-wide Scrum implementation and has some interesting findings.

The second snapshot shows how an Agile coach successfully produced a hyper-productive team every time he became ScrumMaster.  His metrics for hyper-productive teams are something everyone doing Scrum should know about.

The third snapshot describes a companywide transition to Scrum that was executed in two months.   Running headlong into your company’s biggest impediment at full speed is a story not to be missed.  Published results on each of these three snapshots will be available to attendees.

Jeff Sutherland pioneered the development of Scrum with Ken Schwaber in the 1990’s. He teaches Scrum and consults to companies throughout the world on the Scrum framework.


Ken Schwaber

Another year has passed.  More and more people are using Scrum, more organizations are adopting. Scrum has been around long enough that some successes have already started gaining the aches and pains of old age.

This year, Ken will talk about empiricism, the foundation of Agility and Scrum, and what makes it work.  This is of particular importance as the impending winter approaches.

Ken Schwaber is the Scrum pioneer who created Scrum with Jeff Sutherland in the 1990s. Ken is the leader of Scrum.Org, a credentialing and practitioner assessment organization dedicated to improving the professionalism of software development and Scrum practice worldwide.


Dan Mezick

Describing great Scrum is very simple, while doing great Scrum is very hard. What’s the problem here?  The problem boils down to ONE WORD: “authority”.  Teams in Scrum are granted a substantial increase in authority when compared to other ways of working.

Jeff and Ken bristle when you describe Scrum as a “methodology”, or a “process”.  They’ll tell you it is a “framework”….but what kind of framework is it exactly?  Answer: It is an AUTHORITY framework, where each Scrum role is granted specific authority.  These powers do not overlap across the Scrum roles.  The authority of each role is very clear.

Create a great Scrum implementation by paying careful attention to getting agreement– and adhere to Scrum’s clearly specified authority structure. We’ll explore the concepts, do some enlightening exercises, and help you pinpoint exactly where you need to pay close attention in your own Scrum implementation.

Dan Mezick is a trusted Agile adviser and coach to executives, project sponsors, managers and teams developing complex products using Agile and Scrum. He is the president and founder of New Technologies Solutions, Inc.


Ken Schwaber and Jeff Sutherland Authority Panel


Join us for the final session: a Question-and-Answer moderated panel discussion on Scrum with Jeff Sutherland and Ken Schwaber … for a full hour.

Hear direct answers to your thorniest and most difficult Scrum questions! We develop a backlog of questions and present these to Ken and Jeff.

There is sufficient time for ad-hoc, interactive “here and now”, utterly unpredictable and 100% emergent Q&A.



Bob MacWilliams

Bob MacWIlliams plays eclectic instrumentals and songs on acoustic guitar. Bob hails from AUBURNDALE, Massachusetts and plays for us during the break.

More Bob MacWilliams





Feel free to add these photos from the 2010 event to your blog posts about: Give Thanks for Scrum.

All photos Copyright 2010 Tracy White.  Please use this photo credit when republishing.

2010 Give Thanks for Scrum Photos (71 total)

GTfS 2010_37.jpg by IT Event Photography BostonGTfS 2010_38.jpg by IT Event Photography BostonGTfS 2010_39.jpg by IT Event Photography BostonGTfS 2010_40.jpg by IT Event Photography BostonGTfS 2010_41.jpg by IT Event Photography BostonGTfS 2010_42.jpg by IT Event Photography BostonGTfS 2010_43.jpg by IT Event Photography BostonGTfS 2010_44.jpg by IT Event Photography BostonGTfS 2010_45.jpg by IT Event Photography BostonGTfS 2010_46.jpg by IT Event Photography BostonGTfS 2010_47.jpg by IT Event Photography BostonGTfS 2010_48.jpg by IT Event Photography BostonGTfS 2010_49.jpg by IT Event Photography BostonGTfS 2010_52.jpg by IT Event Photography BostonGTfS 2010_53.jpg by IT Event Photography BostonGTfS 2010_54.jpg by IT Event Photography BostonGTfS 2010_56.jpg by IT Event Photography BostonGTfS 2010_57.jpg by IT Event Photography BostonGTfS 2010_58.jpg by IT Event Photography BostonGTfS 2010_59.jpg by IT Event Photography Boston

Please support our sponsors for the event:

See you next year at the 3rd Annual 2011 Give Thanks for Scrum !!

Scrum Authority Mapping


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


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
  • Follow the protocol of the three questions
  • 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 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 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 power.

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 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. 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 is slow to take up their full Role, and is in fact leaving authority on the table. In such cases, the Scrum Master or Product Owner (or someone else) actually picks it 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.

In real-life scenarios, the Authority Map has various odd shapes that vary according to the situation.

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 meant 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 starts to looks like this, the Authority Map profile of a extremely healthy Scrum Team that has excellent execution and no impediments:

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. Similar 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

Case Study Example: Teams Dominated by Product Owner and Scrum Master

The following is an Authority Map of a Team that has problems. The Product Owner is doing certain of the Team’s tasks and is doing so outside the rules of Scrum. Likewise the Scrum Master has grabbed certain tasks reserved for the Team role in Scrum. The result is a Team that cannot function well. Intrusions into the Team role and the taking up of Team tasks by others are depicted in RED in Authority Maps.

The Product Owner (PO) is pulling the work “for the team” or to “help the team” in the Sprint Planning (SP) meeting and is also “helping the team” by carving the Sprint Backlog (SB) into tasks during the Sprint Planning meeting. The Scrum Master (SM) is updating the BurnDown chart which is a task that only the Team is authorized to do in Scrum. This team was train wreck for these reasons.

The coverage in green is very low due to the Team being dominated by the Product Owner and Scrum Master. The other authorized tasks of the Team are not well-executed because of these unauthorized intrusions by the PO and SM. The game of Scrum was poorly played by this group of people.




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 your Scrum implementation.

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.


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

Download: This article as a PDF:  ScrumAuthorityMapsArticleV2

Download: Team Authority Map: TeamA-MapV2

Download: Product Owner Authority Map: ProductOwner-A-MapV2

Download: Scrum Master Authority Map: ScrumMaster-A-MapV2


About the Author

Daniel 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 Daniel Mezick here.