A Scrum Master’s Checklist

An adequate Scrum Master 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 Scrum Master.

A great Scrum Master can handle one team at a time.

We recommend one dedicated Scrum Master 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 Scrum Masters overlook.

  1. 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, highly visible to all stakeholders?
    • If you’re using an automated tool for backlog management, does everyone know how to use it easily? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the Scrum Master.
    • Are you working with the tool supplier to use it to its fullest capacity, or to change it to serve you better?
    • 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 (or front burner, back burner, fridge)?
    • Do all stakeholders (including the team) know whether the release plan still matches reality, based on the current velocity (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.
  2. How is my team doing?
    • Are team members spending some 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. Will the current Sprint Task list satisfy the acceptance criteria of each committed product backlog item?
    • Does the Sprint Task list reflect what the team is actually doing?
    • 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 these artifacts adequately protected from micromanagers?
    • Do team members volunteer for tasks?
    • Are technical debt repayment items (sapping your team’s velocity) captured in the backlog, or otherwise communicated with the Product Owner?
    • Are team members leaving their job titles at the door of the team room?
    • Does the entire team consider itself collectively responsible for testing, user documentation, etc.?
    • Is management measuring the team only by collective success?
  3. 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 constant refactoring, as an alternative to Big Up Front Design? 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, etc. Refactoring with confidence is only possible with automated test coverage. Holes in test coverage and deferred refactoring are cancers called technical debt.
    • Does your definition of “done” (acceptance criteria) 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 dramatically increases 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.
  4. How is the organization doing?
    • Is the appropriate amount of inter-team communication happening? Scrum of Scrums is only one way to achieve this, perhaps not the best way.
    • Are your Scrum Masters 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 Scrum Master is a useless Scrum Master.”)
    • 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.
    • 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?
    • Are you helping to create a learning organization?
  5. 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
    Danube Technologies, Inc.

Download the PDF version (formatted for classroom use).
See an example Scrum Master in action.
Read the 6-page Scrum reference card.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
13 comments on “A Scrum Master’s Checklist
  1. topcoder says:

    As per my experience when the ScrumMaster is a non participating one – ie he does not take on development tasks sooner or later he becomes more like a project manager and this is a major scrum smell which you would like to avoid. This happens because the SM is not longer treated by the team as a team member and slowly they begin to accept whatever he says as order and quickly revert pre-scrum habits. Therefore I would not consider part time SMs. It may work for some teams but not for the ones I’ve seen.

    Plamen RB CSM, MCSD

  2. krivitsky says:


    I took the responsibility of spreading out the wisdom of ScrumMaster’s job by translating a part of this article to Russian.

    A ScrumMaster’s checklist in Russian.

    All links and copyrights are preserved. Thank you!

    Any comments are welcomed!

  3. W says:

    SCRUM means do not complete the work, really?

  4. Laszlo Szalvay says:

    Thanks Krivitsky. I noticed that you referenced back to the original post that Michael had.

  5. Mike Pearce says:

    I have to agree with topcoder. The SM should remain part of the team and, when possible, help with the sprint tasks also, it helps keep the team a tight, cohesive unit.

    Mike Pearce

  6. “…a hyperproductive team — a team that has a great time accomplishing things no one else can…”

    I wonder if the existence of such a team in an organization is a “smell.” Why is the rest of the organization so far out of sync with this team? How can the organization achieve global optimization if there are huge disparities in the effectiveness of different teams? What happens when one team produces output at a rate the rest of the organization can’t consume, and pulls work at a rate the rest of the organization can’t sustain?

    I don’t like the bit about “accomplishing things no one else can.” I would prefer that everyone “can.” I think it should be a goal to raise the bar across the organization rather than to establish one or a few “hyperproductive” teams. The buzz-phrase “hyperproductive team” has become popular recently; I think it is a misguided notion.

  7. Tobias Mayer says:

    I have to agree with Dave about the use of the term hyper-productive. I don’t like it and don’t believe it is what we should be striving for. Hyper implies over, or excess. Dictionary.com says: overexcited; overstimulated; keyed up; seriously or obsessively concerned; fanatical; rabid. Why do we want teams in an over-excited state producing software in excess of what needs to be done? As Dave says, maybe this is a bad smell.

    The goal of a great ScrumMaster is to transform an organization, not to make one team n times better than any other team. That breeds competition, and takes the focus off the greater paradigm shift we are seeking with Agile.

    I wonder if you’d consider finding a new term to replace “hyper-productive” in what is otherwise an excellent article.

  8. Michael James says:

    I agree with Dave and Tobias. How’s this?
    “But if you can envision a team that has a great time accomplishing things you didn’t previously consider possible, and a transformed organization — consider being a great ScrumMaster”

    Per Bas’s suggestion, I’ll also extend section 4 (“How’s my organization doing?”) with things I’ve learned the past couple years.


  9. I like the revision. It makes a world of difference!

  10. Tracy Rockwell says:

    I just heard Diane Rehm on NPR interview Atul Gawande who recently wrote a book called “The Checklist Manifesto”. He is a surgeon who looked at ways of reducing hospital deaths and serious injuries due to failures during medical procedures. What he found was similar patterns kept reoccurring; typically something was dropped from the long list of things that had to be done. He concluded what surgeons needed were checklists. He created several for various procedures and had ten or so hospital’s from third world to top tier hospital’s trial them for a period of time. Overall it reduced errors by 46% and every hospital had minimum double digit reductions which shocked even him. He stressed that what wasn’t needed was a lengthy procedure document, but a quick bullet item checklist that can be read off, for example right before surgery asking if the patient had been given penicillin or does the patient have any underlying medical conditions, etc.

    At my work, almost daily we have battles from people who want to create procedures for every mundane task. Checklists are in essence agile and presumes you know what you are doing, but you simply need a quick reminder least you forget a critical item.

    Here’s the audio for the interview:


    here’s the book:


  11. Denise Hill says:

    I know I’m several years late finding this, but I have a question. What do you mean by “Has your team discovered the useful gray area between system tests and unit tests?”


4 Pings/Trackbacks for "A Scrum Master’s Checklist"
  1. […] A ScrumMaster’s Checklist – a comprehensive checklist from Michael James offering four areas a ScrumMaster should pay attention when coaching: the Team, the Product Owner, the organization and the technical practices. […]

  2. […] was looking for this checklist since some months and now that I’ve found I’ll put it on my desk as a […]

  3. […] A ScrumMaster’s Checklist by Michael James […]

  4. […] A ScrumMaster’s Checklist by Michael James […]

Leave a Reply

Your email address will not be published. Required fields are marked *