A Scrum Master’s Checklist

About 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).

  15 comments for “A Scrum Master’s Checklist

  1. topcoder
    March 27, 2009 at 12:24 pm

    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
    March 27, 2009 at 12:25 pm


    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
    March 27, 2009 at 12:25 pm

    SCRUM means do not complete the work, really?

  4. Laszlo Szalvay
    March 27, 2009 at 12:26 pm

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

  5. November 12, 2009 at 2:05 am

    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. November 12, 2009 at 4:18 am

    “…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. November 12, 2009 at 6:40 am

    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
    November 12, 2009 at 7:35 am

    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. November 12, 2009 at 7:57 am

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

  10. November 13, 2009 at 4:09 am


  11. Tracy Rockwell
    January 8, 2010 at 12:40 pm

    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:


  12. Denise Hill
    October 21, 2014 at 8:21 am

    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?”


Leave a Reply

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