Book Training Contact Us

Scrum Master Checklist

What is a Scrum Master?

In today's unpredictable market environment, the framework known as Scrum is gaining significant attention from many companies.

As one of the three defined roles in Scrum and a symbolic figure within the framework, what kind of presence and accountabilities does a Scrum Master have? The Scrum Guide states the following:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.

The Scrum Guide

Unlike traditional command-and-control leadership, the Scrum Master is required to practice supportive leadership (servant leadership) that empowers the team and organization from within.

They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Guide

Holding a vital role in Scrum, they are in a position to serve the Product Owner, the Developers, and the organization.

To help Scrum Masters identify key focus areas within a typical organization, we introduce "The Scrum Master Checklist".

* This checklist was created by Michael James, a trainer for CSM® and CSPO® courses at Odd-e Japan, and has been translated and utilized in over a dozen languages worldwide.

Are you a full-time facilitator for the team?

A typical Scrum Master supports 2 to 3 teams at a time. If you feel your role is sufficiently fulfilled by simply moderating meetings, keeping timeboxes, and removing the obvious impediments shared by those around you, you might manage it part-time. It likely won't be a fatal mistake.

On the other hand, if you aim to help the team achieve what everyone thinks is impossible and look toward organizational transformation, you can be considered a 'great' Scrum Master.

A 'great' Scrum Master dedicatedly focuses on only one team at a time.

We recommend starting with one full-time Scrum Master for a team of about 7 members.

If you are unsure where to start, begin by understanding the thoughts of the Product Owner, the team, and the organization beyond the team. Observe what is happening right now and examine the team's technology and development methods. While this isn't a universal panacea, I've compiled things that Scrum Masters I've met tend to overlook.

Please mark each of the following boxes with √, ∆, ?, or N/A.
Instructions on how to use these marks can be found at the bottom of the page.

Part I: How is the Product Owner spending their time?

A Scrum Master serves the Product Owner in several ways to increase their effectiveness.

  • Is there only one Product Owner for the product, regardless of the number of teams? (Note 1)
  • Is the Product Backlog prioritized according to the Product Owner’s latest thinking?
  • Are newly discovered requirements and requests being incorporated into the Product Backlog? Remember, the Product Backlog is 'emergent.'
  • Is the Product Backlog a manageable size? To keep it manageable, items at the top should be more granular, while items further down are larger, general 'Epics.' Over-analyzing low-priority items is counterproductive; plans change through ongoing conversations between the team and users/customers.
  • Are the high-priority items in the Product Backlog expressed as INVEST-standard user stories (Independent, Negotiable, Valuable, Estimable, Small, and Testable)? (Note 2)
  • Have you educated the Product Owner about technical debt and how to avoid it? Making automated testing and refactoring part of the Definition of Done (DoD) for every item can be a key to solving this difficult problem.
  • Is the Product Backlog the single source of truth, and is it visible to everyone, including the Scrum Team and external stakeholders?
  • If you use automated digital tools to manage the backlog, does everyone understand how to use them easily? Sadly, digital tools often become 'information refrigerators' that hinder team collaboration.
  • Are you helping communicate information by teaching others how to create large, easy-to-read charts?
  • Have you assisted the Product Owner in adjusting Product Backlog items to enable timely releases and better prioritization?
  • Do the Scrum Team and stakeholders know if the release plan is up to date? Consider updating and sharing a Product or Release Burndown Chart (Note 3) after items are marked 'Done' in the Sprint Review. Graphing the ratio of completed items to new items helps identify schedule/scope drift early.
  • Has the Product Owner adjusted the release forecast after the Sprint Review? If you want to ship a well-tested product by a specific date, you must constantly re-evaluate scope. Some items may need to be deferred if more critical work is discovered. Depending on the product, you might release every Sprint or even multiple times within a Sprint.

Part II: How is the Developers' situation?

A Scrum Master is expected to lead by example in collaborating with team members, yet there is a constant risk of becoming too immersed in technical tasks. Let's reflect on your primary responsibilities to the team.

  • Is your team in a state of Flow? (Note 4) Characteristics of this state include:

    • Clear goals (expectations and rules are clear; goals are attainable and match your skills).
    • Focus and concentration (the ability to direct attention to specific tasks or limited areas).
    • A loss of self-consciousness (being fully immersed in the work).
    • Direct and immediate feedback (successes and failures are clear, allowing for real-time adaptation).
    • A balance between challenge and skill (the activity is neither too easy nor too difficult).
    • A sense of personal control over the situation or activity.
    • Intrinsically rewarding activity (finding joy in the work itself).

  • Are the team members comfortable with each other, sharing jokes and celebrating each other's successes?
  • Do team members hold each other to high standards of accountability and challenge one another to grow?
  • Are there any 'elephants in the room'—problems that the team is avoiding despite the need to discuss them? (Note 5)
  • Have you experimented with various techniques or fresh locations for the Sprint Retrospective? (Note 6)
  • Does the team remain focused on the Sprint Goal? It might be helpful to establish a mid-Sprint check-point to review the Sprint plan.
  • Does the Sprint Backlog accurately reflect what the team actually plans to do and has done? Beware of 'dark matter' (Note 7)—unlisted tasks known to no one or tasks larger than a day's work. Work unrelated to the Sprint hinders its progress.
  • Is your team composed of 3 to 9 members with sufficient cross-functional skills to build a shippable product?
  • Is the Sprint Backlog kept up to date?
  • Are the artifacts self-managed by the team visible and easy for them to use?
  • Are these artifacts protected from meddling by people outside the team? Excessive checking by outsiders can undermine internal transparency and self-management.
  • Do team members work with the spirit of volunteers? My first Scrum team felt like 'volunteers who happened to be paid.' If your team doesn't feel this way, something might be wrong.
  • Is the need to repay technical debt explicitly included in the Definition of Done, making the act of writing code more enjoyable and sustainable?
  • Do team members take collective responsibility for all aspects of the agreed work (testing, user documentation, etc.) rather than sticking only to their job titles?

Part III: How are the Engineering Practices?

  • In the system you are developing, is there an environment that makes it easy to detect regression test failures (when previously working features break)? Typically, this is achieved using xUnit frameworks (JUnit, NUnit, etc.) or E2E testing tools (Cucumber, etc.).
  • Is there an appropriate balance between automated end-to-end system tests (functional tests, etc.) and automated unit tests?
  • Does the team write both system and unit tests in the same programming language as the system under development? Using proprietary script languages or capture-replay tools that only a few members know how to maintain does not promote collaboration.
  • Has your team discovered the useful 'gray zone' (Note 8) between system testing and unit testing?
  • Does your CI (Continuous Integration) (Note 9) server automatically issue warnings when a regression test fails? Can you shorten this feedback loop to hours or even minutes? ('Daily builds are for wimps.' — Kent Beck)
  • Are all test results uploaded to the CI server?
  • 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 without changing external behavior.' It should happen continuously—ideally several times an hour. Refactor whenever you find duplicate code, complex conditional logic (indicated by deep nesting or long methods), poorly named identifiers, or excessive coupling. Automated test coverage is essential for refactoring with confidence. Neglecting refactoring makes future changes difficult, especially since it's hard to find talented developers willing to work on bad code.
  • Does your 'Definition of Done' include fully automated test coverage and refactoring for every PBI? Learning TDD (Test Driven Development) will help make this a reality.
  • Do team members spend a significant portion of their development time in pair or mob programming? These practices significantly improve maintainability and reduce defect rates. While they challenge individual boundaries and may seem slower at first (if measured by lines of code rather than shippable features), a Scrum Master should lead by example. Eventually, many find they prefer working this way.

Part IV: How is the Organizational situation?

  • Is communication between teams handled appropriately? 'Scrum of Scrums' is just one way to achieve this, and often not the best way. (Note 10)
  • Is the team capable of producing working software (results that customers can evaluate)? Is the team cross-functional, spanning different architectural and technical layers? (Note 11)
  • Do multiple teams within the organization conduct Overall Retrospectives to resolve cross-team, organizational, and systemic issues? (Note 12)
  • Are organizational impediments posted on the walls of managers' offices to ensure high transparency? Can you quantify the costs of wasted time-to-market, lost quality, and missed customer opportunities in monetary terms? (Learn from Ken Schwaber: 'A dead ScrumMaster is a useless ScrumMaster.') (Note 13)
  • In your organization, do team goals and HR performance evaluations work in harmony as two sides of the same coin? If the culture rewards programming or architectural work at the expense of testing, automation, or documentation, the answer is likely 'No.' (Note 14)
  • Is your organization recognized by industry publications or independent bodies as a 'Great Place to Work' or as having exceptional leadership?
  • Are you creating a 'Learning Organization'?

Conclusion

If you have checked off most of these items and still find yourself with extra time, I would love to hear your story. There is no fixed formula for sparking human ingenuity. The points listed in this checklist may or may not be helpful to you. Once you start thinking about what you can do to bring about change in your team and organization, you might feel a sense of fear about taking action. That feeling is proof that you are on the right path as a Scrum Master.

How to Use the Checklist

If you received this checklist as part of a workshop or training, or if your current (or most recent) employer is practicing something like Scrum, please mark the items based on your own observations. Fill in each box with one of the following:

  • √ : Already achieved / In place
  • ∆ : Room for improvement, and I know how
  • ? : Improvement/Challenge seems possible, but I don't know how yet
  • N/A : Not applicable or provides no benefit

If your current (or most recent) employer is NOT practicing anything like Scrum, fill in each box with one of the following:

  • √ : Already achieved or seems easy to achieve
  • ∆ : Could be a challenge, and I know how to start
  • ? : Improvement/Challenge seems possible, but I don't know how yet
  • N/A : Not applicable or provides no benefit

Once you have completed the checklist, declare 2 to 6 organizational challenges in your Organizational Improvement Form, regardless of whether they were explicitly mentioned in this list. Choose challenges where you believe there is at least a 1% chance of making an improvement.

Organizational Improvement Form

  • Surfaced Issue:
  • Root Cause (Ask 'Why' 5 times):
  • Business Impact:
  • Emotional Impact:
  • Clear and Actionable Next Steps:

How to Systematically Learn the Role of a Scrum Master

At Odd-e Japan, we offer Certified ScrumMaster® (CSM®) training, a Scrum Alliance® certified program.

Courses are led by Kazumasa Ebata (ebacky), CEO of Odd-e Japan and a Certified Scrum Trainer® (CST®). We also frequently host sessions featuring international guest trainers.

The CSM® training conducted by Kazumasa Ebata (ebacky) follows a unique approach where the agenda is co-created with the participants. (*This flexible, participant-driven style is a privilege reserved only for highly experienced CSTs®). Below are examples of topics covered in past agendas:

  • Introduction
  • History
  • Self-organizing Organizations
  • Scrum Overview
  • Scrum Roles
  • Scrum Events (Ceremonies)
  • Scrum Artifacts
  • Impediments to Scrum
  • Acceptance Criteria and 'Done'
  • Technology & Engineering
  • Scaling Scrum
  • Course Conclusion
Odd-e Japan Official Training

By attending CSM® training, you will gain the following foundational knowledge of Scrum:

  • Gain a deep understanding of Scrum Master fundamentals.
  • Become a (more effective) change agent for your organization and team.
  • Develop the skills to serve as a (better) Scrum Master for your team.
  • Enhance your contributions as a Scrum Team member.
  • Improve your effectiveness as a Product Owner within a Scrum Team.
  • Effectively explain Scrum to others in your capacity as a Scrum Master.
  • Experience firsthand what it means to be part of a self-organizing team and organization.
  • Learn how to measure and reduce 'time-to-market' through Scrum practice.
  • Identify common illusions and pitfalls that people face during product development through experiential learning.
  • Gain actionable insights for improving project management and product development, even if you cannot immediately implement full Scrum.
Odd-e Japan Official Training

Summary

We hope this was helpful. To become a 'great' Scrum Master, it is essential to look beyond the immediate Product Owner and Developers you work with; you must also identify and support challenges within the surrounding organization and corporate systems. Since the knowledge and skills required for a Scrum Master are so diverse, continuous self-growth through the practice of Scrum is vital. We encourage you to revisit this checklist periodically to reflect on your own progress and challenges.