Get certified - Transform your world of work today


An Example ScrumMaster's Checklist

2 November 2010

An adequate ScrumMaster can handle two or three teams at a time. If you're content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn't previously consider possible, within a transformed organization -- consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.

If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's engineering practices, and the organization outside your team. While there's no single prescription, I've outlined some things I've seen ScrumMasters overlook.


How is my Product Owner doing?  

You improve the Product Owner’s effectiveness by helping maintain the Product Backlog and release plan. (Note that only the Product Owner may prioritize the backlog.)

__  Is the Product Backlog prioritized according to his/her latest thinking?

__  Are all the requirements and desirements from all stakeholders for the product captured in the backlog? Remember the backlog is emergent.

__  Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It's counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.

__  Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories?

__  Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be adding automated test and refactoring to the definition of "done" for each backlog item.

__  Is the backlog an information radiator, clearly visible to all stakeholders?

__  If you're using an automated tool for backlog management, is it actually working for you? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.

__  Can you help radiate by showing everyone printouts?

__  Can you help radiate by creating big visible charts?

__  Have you helped your Product Owner organize backlog items into appropriate releases (e.g., front burner, back burner, fridge)?

__  Do all stakeholders (including the team) know whether the release plan still matches reality, based on the current velocity (e.g., story points per Sprint)?

__  Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time replan the release every Sprint, usually deferring some work for future releases as more important work is discovered. You might try showing everyone the Mike Cohn-style Product/Release Burndown Charts after the items have been acknowledged as “done” during every Sprint Review Meeting. This allows early discovery of scope/schedule drift.



How is my team doing?

__  Are team members spending most of their time in the state of flow?  Some characteristics of this state (from Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi):   Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one's skill set and abilities);  Concentrating and focusing, a high degree of concentration on a limited field of attention;  A loss of the feeling of self-consciousness, the merging of action and awareness;  Distorted sense of time - one's subjective experience of time is altered;   Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed);   Balance between ability level and challenge (the activity is neither too easy nor too difficult);   A sense of personal control over the situation or activity;  The activity is intrinsically rewarding, so there is an effortlessness of action.

__  Do team members seem to like each other, goof off together, and celebrate each other's success?

__  Do team members hold each other accountable to high standards, and challenge each other to grow?

__  Are there issues/opportunities the team isn't discussing because they're too uncomfortable? See Crucial Conversations: Tools for Talking When Stakes are High.  Or consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable.

__  Have you tried a variety of formats and locations for Sprint Retrospective Meetings?  See Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) for some ideas.

__  Has the team kept focus on acceptance criteria? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the product backlog items committed for this Sprint.

__  Does the Sprint Backlog reflect what the team is actually doing?  Interruptions and distractions that don't contribute to Sprint goals are impediments.

__  Are your team's task estimates and/or your taskboard up to date?

__  Are the team self-management artifacts (taskboard, Sprint Burndown Chart, etc.) visible to the team, convenient for the team to use?

__  Are the team self-management artifacts adequately protected from micromanagers?

__  Do team members volunteer for tasks?

__  Are technical debt repayment items (to address issues sapping your team's velocity) captured in the backlog, or otherwise communicated with the Product Owner?

__  Are team members leaving their job titles outside the team room?

__  Does the entire team consider itself collectively responsible for testing, user documentation, etc.?




How are our engineering practices doing?


 __  Does your system in development have a "push to test" button so that anyone (same team or different team) can conveniently detect when they've broken it? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).

 __  Do you have an appropriate balance between automated end-to-end system tests (a.k.a. "functional tests") and automated unit tests?

__  Is the team writing both system "functional" tests and unit tests in the same language as the system they're developing (rather than using proprietary scripting languages or capture playback tools only a subset of the team knows how to maintain)?  It's possible.

__  Has your team discovered the useful gray area between system tests and unit tests?

__  Does a continuous integration server automatically sound an alarm within an hour (or minutes) of someone causing a regression failure? ("Daily builds are for wimps." -- Kent Beck)

__  Do all tests roll up into the continuous integration server result?

__  Have team members discovered the joy of continuous design and merciless refactoring, as an alternative to Big Design Up Front?  Refactoring has a strict definition: changing the internal structure of a system without changing its external behavior.  Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, excess responsibility in one object, etc.  Refactoring with confidence is practical with automated test coverage.  Holes in test coverage and deferred refactoring are cancers called technical debt.

__  Does your definition of "done" for each functional Product Backlog Item include full automated test coverage and refactoring?  You╩╝re unlikely to build a potentially-shippable products every Sprint without learning eXtreme Programming practices (as described by Kent Beck, Ron Jeffries, etc.).

__  Are team members pair programming most of the time?  Pair programming can dramatically improve code maintainability and reduces bug rates.  But it challenges people's boundaries and sometimes seems to take longer (if we put quantity over quality).  Rather than force people to do this, lead by example by initiating paired workdays with team members.  Some of them will start to prefer working this way.





How is the organization doing?

__  Is the appropriate amount of inter-team coordination happening?  Scrum of Scrums is only one way to achieve this.  Also consider sending ambassadors to other teams' standups.

__  Is the inter-team coordination done by the people with their hands dirty in the work, as recommended?

__  Are your ScrumMasters meeting with each other, working the organizational impediments list?

 __  When appropriate, are the organizational impediments pasted to the wall of the development director's office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But remember Ken Schwaber's discovery: "A dead ScrumMaster is a useless ScrumMaster.")

__  Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer "no" if there's a career incentive to do programming or architecture work at the expense of testing, test automation, or user documentation.

__  Are you helping to create a learning organization?

__  Has your organization been recognized by the trade press or other independent sources as one of the best places to work or a leader in your industry?



Fear Is Your Friend


Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a sign you're on the right track.


Software Process Mentor, author of

also: Download the PDF version (classroom use instructions on last page)
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.4 (55 ratings)


Arran Hartgroves, CSP,CSM, 11/19/2010 5:07:34 PM
Great article, definitely be using this.

One point, regarding "Are all the requirements and desirements from all stakeholders for the product captured in the backlog? Remember the backlog is emergent.". Would it be easier to only capture the items essential to the next product's release (in line with the vision)?
Arran Hartgroves, CSP,CSM, 11/19/2010 5:08:37 PM
Also, great point about information refrigerators!
Mike Barlotta, CSP,AdvCsm,CSD,CSM, 11/29/2010 11:31:14 AM
Thanks for sharing these check lists.
Jan Beaver, CST,CSP,CSM,CSPO,REP, 11/29/2010 8:10:07 PM
Very nice. Some extremely important reminders for ScrumMasters and their ever-hopeful coaches.
Rajesh Francis, CSM, 9/27/2011 4:09:13 AM
I will be using this as my checklist in my projects. Great post.
Glen Wang, CSM, 6/5/2013 12:23:59 AM
State of flow is not easy. We are living in a complex world rather than a pure Scrum box. The center of work is people. The center of people is heart. The center of heart is philosophy. I think an organization need build its own philosophy. The philosophy of Unity of Knowing & Doing can help Scrum to let people do the right things.
Nas Nassam, CSM,CSPO, 8/10/2013 11:22:32 PM
Great Article. Thank you for sharing.
Anonymous, 4/30/2014 9:39:59 PM
MJ, you do great work. Thanks for making this list for others to reference.
Sekhar Burra, CEC, CST, CST,CEC,CTC,CSP,CSM,CSPO,REP, 5/22/2014 2:17:32 AM
Mike, You nailed it. Infact, a Scrum Master must have great people skills to be succesful in the role.
Anonymous, 9/9/2014 4:45:59 PM
Excellent Check list!
Bob Lieberman, CSP,CSM, 2/3/2015 2:18:58 PM
When I was starting out, I thought the "great scrum master" quote was cool and inspiring. Now that I have some dirt in my shoes I think it is misleading, because it implies that the team has free rein to create whatever magic it wants -- something that is out of the scrum master's hands and is, in many organizations, impossible.

The corresponding "great" team needs to have the freedom to go as fast and as far as it can. The reality is that most organizations can't assimilate a team like that, because the organization can't or won't (for good and bad reasons) adapt its practices and values to make that magic possible.

The bad reasons are ones we're all aware of: sloth, poor management, command-and-control mentality, and so on. But there are good reasons, too: product complexity, demands of the marketplace, capabilities of the available labor pool, etc.

In my experience, the "great scrum master" spends most of his/her time working the organizational issues. I think that is the defining factor. If the organization responds quickly and enthusiastically, just one team could benefit from the fast pace of improvement and creativity. But if the organization doesn't do that, the pace slows, and the "great scrum master" can handle more than one team.

As discouraging as this may sound, if the "great scrum master" at a less-than-great organization succeeds in fostering deep organizational change over a longer period of time than we would like, the benefit may be equally profound.

The proverbial large ship does take longer to turn, but it can deliver value in a volume that is worth the wait.

It might be useful for the Scrum community to provide more breadth in its vision of perfection, so that scrum masters can aspire to greatness in ways that align better with more of the kinds of work and value that are out there.
Michael James, CST,CSP,CSM,CSPO,REP, 2/16/2015 3:50:50 PM
Thanks for your comments Bob. I agree that the ScrumMaster's focus shifts from the team to the outer organization, as many of the team's problems will come from the outer organization: issues of organizational design, HR practices, etc. I'd like to expand the last section "How is your organization doing?" to include more of those issues.
Michael James, CST,CSP,CSM,CSPO,REP, 5/19/2015 6:49:46 PM
The link below is one of the best descriptions I've seen of the ScrumMaster's role in a large organization. It also describes the shift in focus away from the team toward the organization.
Mitsuo Hangai, CSP,CSM,CSPO, 6/11/2015 11:13:27 PM
Hi, I came here from
Can I translate this article to Japanese? This checklist is extremely great.
Siba Prasad Choudhury, CSM, 10/14/2015 1:40:27 AM
Great learning, Exhaustive checklist to muse all the time.
Prabhakar Palem, CSP,CSM, 2/22/2016 7:35:56 AM
Thanks for sharing Check list
Daniel Pérez, CSM, 3/3/2016 11:46:32 AM
Thanks for sharing the Check list, is very useful for the full time scrum masters!
Karen Richmond, CSM, 3/16/2016 3:02:55 PM
This is a wonderful checklist to use.
Michael Plett, CSM, 4/9/2016 9:07:33 AM
Thanks for sharing your Check List
Nathan Turney, CSM,CSPO, 4/25/2016 5:18:46 AM
A really great checklist which i can see great benefit in keeping hold of! Really good for new CSM's like myself! Thank you very much!
Excellent checklist!!! Thanks for sharing.
Sureshchandra Sharma, CSP,CSM,CSPO, 5/5/2016 2:46:57 AM
Wonderful, thanks for sharing!!
Sze Wing Austen, CSM, 5/31/2016 11:24:35 PM
This is a great start, thank you! With this planning for each role and process for the future is easier.
Rajkumar Muthuswami, CSM, 7/26/2016 9:29:10 AM
Thanks for sharing the details. will be very useful for us
Patrick Szalapski, CSP,CSD,CSM, 9/19/2016 10:31:17 AM
I really like this checklist, but it strikes me as more "intermediate"; I find many Scrum Masters need the more basic checklist first, which I have tried to formulate here: Would love feedback on it.
LUIZ LIMA, CSP,CSM,CSPO, 4/26/2017 9:53:36 PM
Excelente artigo. Quando começamos a escalar o Scrum, os desafios irão só aumentando! Quem disse que seria fácil?! Isso é desafiador, é muito bom.
Leesa satapathy, CSP,CSM,CSPO, 6/6/2017 3:12:50 AM
Great Article and the checklist as said by many is exhaustive...
Harsha Vardhan Tirumandas, CSM, 7/20/2017 11:27:12 PM
Thanks for sharing a great article.
Yagna Vardhan Thogarcheti, CSM, 11/10/2017 9:14:54 AM
That is really nice checklist for Scrum Master!! Thanks a lot for sharing!!!
Dipesh Majumder, CSM, 11/20/2017 9:18:39 PM
Thanks for sharing this checklist!
Mayank Saxena, CSM, 2/15/2018 12:12:03 AM
Thanks for the checklist. It really helps to understand the subtle role of SM as the most of the responsibilities seems to be of PO or Dev team. Really helpful checklist.

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