Get certified - Transform your world of work today


ScrumMaster Maturity Model

A Case Study

30 July 2013

Jerry Rajamoney
Visa Inc.

This article illustrates some of the key things I learned after trying out the ScrumMaster Maturity Model (SM^3™) by the Braintrust Consulting Group. As an Agile coach, I work with multiple Scrum teams, ScrumMasters, and product owners. I have tried this model with few of the Scrum teams, as pilots, and I gained a lot of insights. The data shown are real and presented as collected.

We are all aware that Scrum is the most widely used Agile development framework today in the software industry. Scrum is a simple framework that helps a team inspect and adapt on an ongoing basis. One of the interesting roles Scrum introduced is the ScrumMaster role.

This ScrumMaster role is unique, and some of the key expectations are:
One of the key challenges I have faced while working with multiple Scrum teams is how the make the ScrumMasters more effective. Is there a way for me to see where the ScrumMasters stand in terms of their roles and responsibilities? Do I get some measurement criteria that are easy to use and at the same time give good insights, so that the ScrumMaster can use them and improve his or her way of working?

To get answers to these questions, I started exploring and came to know about the ScrumMaster Maturity Model (SM^3), developed by Brian Rabon, CST, PMP, president, the Braintrust Consulting Group. This model was recently presented at the 2013 Scrum Alliance Global Gathering in Las Vegas.

ScrumMaster Maturity Model
Here is a quick introduction to Rabon's model. It is based on a simple questionnaire that contains ten questions. Each question is multiple choice, and each team member is expected to pick the option that he or she believes resembles the behavior of the ScrumMaster.

Each option selected has a numeric value attached to it. After answering the ten questions, you can sum up the values associated with the selected options. Based on that final value, the ScrumMaster is placed within a scale of 1 to 5. Each level has a title, such as: 1 = Wolf in sheep's clothing, 2 = Scrum scribe, 3 = Facilitator, 4 = Coach, 5 = Servant leader. For a complete presentation and details about the ScrumMaster Maturity Model, please visit the website

Modifications to the original model
When I tried to implement this model in one of the Scrum teams I'm coaching, I added the following dimension:
  • The ScrumMaster and the team members participate in this process.
  • The options selected for each question by the ScrumMaster and the team members will be plotted in a graph that shows how the ScrumMaster thought he or she was performing in the expected role, as well as and how the team actually perceived that performance. It is similar to a 360-degree feedback process.
Data collection
I proposed this model as a pilot activity to one of my Scrum teams, and the team agreed to try it. We  had a 30-minute Wednesday afternoon meeting that included the full-time ScrumMaster and the five team members. Each person, including the ScrumMaster, received a copy of the questionnaire, filled it out (without discussion), and returned it to me.

When I plotted the data, I found some unique patterns. Here I'll share two charts and the insights they provided to all of us.

Data and results
First scenario

Question Shown / performed behavior
Two team members don't get along and are constantly fighting. It's disturbing the other team members and they have asked you to deal with it. What should you do? a) Bring the conflict up with your human resources representatives and ask them to solve it.
b) Hold an all-hands team meeting and refuse to end it until the issue is resolved.
c) Meet with the two team members and do a root-cause analysis of why they're fighting.
d) Ask management to move one of the fighting team members to another team.
When I plotted the data collected from both the ScrumMaster and the team, here is what appeared:
The ScrumMaster selected option 3, which is C (meet with the two team members and do a root-cause analysis of why they're fighting). The entire team selected the same option. Hence all answers were the same.

In a detailed discussion with the ScrumMaster and the team later on, it became clear that the way of working exhibited by the ScrumMaster was clearly visible, and the team acknowledged his involvement in removing impediments and helping them self-organize.

Second Scenario
Question #2 from Rabon's model was as follows:

Question Shown / performed behavior
A team member is late every day for the daily Scrum. What should I, the  ScrumMaster, do? a) Ignore the issue; the team is self-organizing.
b) Fine the team member $10 each time it happens.
c) Bring the lateness up at the next retrospective.
d) Publically chastise the team member for showing up late.
When I plotted these data, this is what I found:
The ScrumMaster selected option 3, which is C (Bring the lateness up at the next retrospective), but the complete team selected option 1, which is A (Ignore the issue; the team is self-organizing).

In the detailed discussion with the ScrumMaster and the team later on, it was clear that the ScrumMaster made the wrong assumption, from the team's point of view, in this scenario. And he felt it was the team's responsibility, not his, to discuss the problem in the retrospective meetings.

I have tried the ScrumMaster Maturity Model with two business units in which we have eight Scrum teams and six ScrumMasters. I've reviewed the results with all the six ScrumMasters, along with their teams. I personally have seen this model help the ScrumMasters measure their work and also validate their way of working against their own as well as their teams' perspectives.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.2 (6 ratings)


Glen Wang, CSM, 7/30/2013 12:54:06 AM
Interesting! Each level has a title, such as: 1 = Wolf in sheep's clothing, 2 = Scrum scribe, 3 = Facilitator, 4 = Coach, 5 = Servant leader.
G. Manto, CSP,CSM,CSPO, 7/30/2013 6:14:07 AM
This is great food for thought. If possible, it would be useful to hear about how things turned out 2 to 3 sprints after the assessment was done. I think some the subjective and objective influencing factors might start to reveal themselves.
Dyaneshwaran Periyasamy, CSP,CSM,CSPO, 8/4/2013 8:06:41 AM
Hi Jerry, thanks for sharing the data. It was useful.
Brian M. Rabon, CST, PMP, CST,CALE,CSP,CSD,CSM,CSPO,REP, 8/9/2013 7:21:43 PM
Jerry, thank you for innovating on our ScrumMaster Maturity Model (SM^3) and sharing your experiences with the community. If anyone would like to get a copy of our model and do your own application you can download it here Let us know your experiences please.
Tom Mellor, CST,CSP,CSM,CSPO,REP, 10/14/2013 1:03:26 PM
Interesting. I have some issues with the BT Maturity Model, and since I am a member of the Braintrust team, I suppose that is ok. I continue to maintain as I always have that the ScrumMaster is a servant first and (perhaps) a leader second. Having served in the role on many, many projects, I can say for certain that service to the development team is the first priority of the ScrumMaster. When team operate autonomously and rely on emergence of leadership, there will be a natural tendency for people to want to "lead." What this often means is they want to "control." Leading is influencing; managing is controlling. The SM role is not an easy one and is even more complicated for many because it indicates no authority over the Scrum team. That can be at once discomforting and empowering. But, influence is an art and not easily learned or mastered. And influencing from an informal position deliberately void of power is more than a challenge for many. You better be comfortable with your vulnerability, as Brene Brown advocates in her Ted Talks. CMMI smells of an anti-Scrum pattern to me and I dislike its metaphorical use in instances like this. I prefer the essence of "Shu Ha Ri" as I teach in my classes. The road to Ri is a long and arduous one. As a borrowing from an old Montana Cowboy saying: "Good ScrumMaster judgment comes from experience, and a lot of that comes from bad ScrumMaster judgment." And, it's worthwhile to learn cowboy ways from long-time cowboys; same goes for ScrumMasters.
Muthaiya Nallalam Parasuraman, CSP,CSM,CSPO, 7/8/2014 4:23:26 AM
This maturity model shows the scrum knowledge of SM. maturity of a scrum master should be also measured by the team's transformation. None of the question points to that. Correct me if I missed something.

Further more ,
For question 4.
At the sprint review meeting I…
a) Focus on the teams
accomplishments and successes
b) Seek stakeholder feedback on the
product and how to make it better
c) Observe and take notes for the
d) Lead the demo

For the above question option A is given a high point. I have to disagree. The scrum master is not a appraiser for developers. Sprint review is for stakeholders to provide feedback. The missed out items and new items should go to product backlog. This meeting forms the basis for sprint planning of the future sprints. So if I was the SM I will take notes of stakeholder, DT and PO approach to the sprint review. And give them feedback on how to adapt better in the future. Accomplishments will be focused in retrospective.
Another question....
Question 8.
The team’s burn down chart shows that they
won’t complete the sprint backlog by the end of
the sprint, what should you do?
a) Let the product owner know that the team
won’t complete their sprint goal
b) Demand that they team work overtime until
they catch up
c) Call attention to the burn down chart in the
next daily Scrum
d) Suggest to the team that they extend the
sprint until they can finish everything

This question gives 4 points for C. I have disagreements. By calling attention to burn down chart, we are deviating from the purpose of daily scrum. Daily scrum is for team members to make it transparent what they are doing to achieve the sprint goal and the related road blocks. Furthermore, burn down chart is available to most of the team all day. It just will show we are delayed. By pointing it to the teams face, SM is playing project manager? SM is supposed to first inform the PO that there could be a delay. So that PO would bring less surprise to stakeholder or re-prioritize. Information is vital here. After this, SM listens in the daily scrum to see what the impediment is. Facilitate PO to maximize the work not done without interfering in the sprint goal.

These are my thought. I expect someone to correct me if I am wrong. Feedback welcome.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up