An Example Checklist for ScrumMasters

Michael James

(mj4scrum@gmail.com)

14 September 2007

(Revised 2 Feb 2016)

A Full Time Facilitator?

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 no one previously thought 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 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 for everyone,

I've outlined typical things I've seen ScrumMasters overlook. Please mark each box with √, ∆, ?, or N/A, as

described on the last page.

Part I -- How Is My Product Owner Doing?

ScrumMasters improve Product Owner effectiveness by helping them find ways to maintain the Product Backlog

and release plan. (Note that the Product Owner is the one responsible for the prioritized backlog.)

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

Are requirements and desirements from all stakeholders captured in the Product 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 to write automated test and refactoring into the definition of "done" for each backlog item.

Is the backlog an information radiator, immediately 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 ScrumMaster.

¹ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Can you help radiate information by showing everyone printouts?

Can you help radiate information by creating big visible charts?

Have you helped your Product Owner organize backlog items into appropriate releases or priority groups?

Does everyone know whether the release plan still matches reality? You might try showing everyone Product/

Release Burndown Charts² after the items have been acknowledged as “done” during every Sprint Review

Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery

of scope/schedule drift.

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 re-plan the release every Sprint. This probably requires

deferring some work for future releases as more important work is discovered.

Part II -- How Is My Team Doing?

While you are encouraged to lead by the example of collaborating with team members on their work, there is a

risk you will get lost in technical tasks. Consider your primary responsibilities to the team:

Is your team in the state of flow? Some characteristics of this state³:

• Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with

one's skill set and abilities).

• Concentration and focus, 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.

• 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?⁴

Have you tried a variety of formats and locations for Sprint Retrospective Meetings?⁵

Has the team kept focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the

acceptance criteria of the Product Backlog Items committed for this Sprint.

² Mike Cohn, Agile Estimation and Planning. (2005).

³ Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).