Scrum Master Checklist

Scrum Master

But if a Scrum Master wants to turn a team into an agile team for everyone to see, they need to think about how to be a good Scrum Master and guide the team better. The Scrum Master best serves as a full-time facilitator for a group, especially in the early stages.

Here is a checklist for Scrum masters to see where they can lead the team:

Ⅰ. How is the product owner doing?

Scrum Masters can improve the productivity of product owners in several ways:

• Is there only one product owner for a product, regardless of how many teams there are?
• Is the product backlog prioritized according to the latest thinking of the product owner?
• The backlog is constantly updated. Are the new feedback requirements already on the product backlog?
• Is the number of product to-do lists manageable? To maintain a manageable number of to-do items, you need to refine the granularity of high-priority items, while low-priority items can remain coarse-grained. Overanalyzing low-priority to-do lists is counterproductive because requirements are constantly changing.
• Can requirements (exceptionally high priority ones) be expressed as independent, negotiable, valuable, estimable, small, and testable user stories?
• Is the product owner paying attention to and avoiding technical debt issues? Include automated testing and refactoring in the "done" definition of a to-do list.
• Is the to-do list visible to all stakeholders?
• Do team members understand how to use automated tools to manage to-do lists? Because the incorrect introduction of automation tools is often detrimental to collaboration.
• Is it possible to facilitate the dissemination of information through more macroscopic visualization?
• Do you help product owners prioritize their to-do lists?
• Do all stakeholders (including the team) know how the release plan fits into the team's current rate? Try demonstrating the product or publishing a burndown diagram at each Sprint review meeting after confirming that the project is "done," that will allow us to detect deviations in scope and time in a more timely manner.
• Will the product owner change the release schedule after the Sprint review? Some product owners will adjust their release plans as soon as Sprint delivers. As other important work continues to be discovered along the way, some of the original work is delayed.

Source: www.sohu.com

Ⅱ. How's the team doing?

• Is the team fluid? The average smooth team has the following characteristics:

a. Clear goals (expectations and rules are visible, goals are achievable, and are appropriately matched to the individual's skills and abilities);

b. To give all one's attention and energy；

c. In the lower state of consciousness, action, and cognition are united;

d. Direct and timely feedback (behavior can be constantly adjusted with feedback);

e. Strike a balance between competence and challenge (not too easy, not too hard);

f. Control of a situation or task;

g. There is intrinsic motivation, so it is easy to work.

• Do team members cooperate, understand each other, and often celebrate project successes？
• Do team members monitor and challenge each other to high standards for growth?
• Are there any topics that aren't discussed in the group because people feel uncomfortable?
• Have you tried doing Sprint retrospectives in different formats and locations?
• Does the team focus on acceptance criteria throughout the Sprint? Consider a mid-sprint review to re-evaluate the Sprint plan.
• Do Sprint tasks reflect what the team is doing? Non-sprint-related work is a hurdle for Sprint.
• Does the team consist of 5-9 cross-functional people? Can you build potential deliverable product increments?
• Does the team's task board contain up-to-date information?
• Are the artifacts the team uses for self-management (task boards, Sprint burn charts, and so on) visible to the team? Is it easy to use?
• Are these artifacts adequately protected from outside interference? Excessive scrutiny of team activities by people outside the team can hinder transparency and self-management within the team.
• Will team members volunteer for tasks? On a Scrum team, you should feel like a paid volunteer. If it doesn't, something is wrong.
• Is the need to pay off technical debt on your to-do list? If not, did the team communicate with the product owner?
• Can team members set aside their job definitions and take collective responsibility for all aspects of the agreed work (tests, user documentation, etc.)?
• Does management measure teams by their collective success?

Source: www.sohu.com

Ⅲ. How is the engineering practice going?

• Does the system under team development have a "press test" button that makes it easy for everyone (on the same team or different teams) to detect that the system is broken? That is usually done using the XUnit framework (JUnit, etc.).
• Is there a proper balance between automated end-to-end system testing (or functional testing) and automated unit testing?
• Does the team write system functional and unit tests in the same language as the development system (as opposed to a specialized scripting language or capture-playback tool that only some of the team knows how to maintain)?
• Did the team find a good gray area between system and unit testing?
• Does a continuous integration server automatically sound an alarm within an hour or even a few minutes when someone causes a regression failure?
• Are all tests summarized in the results of the continuous integration server?
• Do team members find continual design and refactoring fun? Refactoring is strictly defined as changing the internal structure of a system without changing its external behavior, in the case of duplicate code, complex conditional logic, poorly named identifiers, excessive coupling between objects, and so on. Refactoring should be continuous, at least several times per hour. Refactoring can only be done with confidence if automated test coverage is available.
• Does the definition of "done" on the product backlog include complete automated test coverage and refactoring? Test-driven development (TDD) increases the likelihood of achieving this goal.
• Do team members pair most of the time? Pair programming can significantly increase the maintainability of code and reduce Bug rates.

Ⅳ. How is the team/organization doing?

• Is there adequate communication between teams? Scrum of Scrums is one way to achieve communication.
• Can teams deliver work independently when they need to cross architectural boundaries?
• Is a comprehensive review conducted within the organization to address cross-team, system-wide issues?
• Where appropriate, are team barriers posted on the wall of the R&D lead's office? Can these barriers be quantified as lost money, time to market, quality, or customer leads?
• Is a comprehensive review conducted within the organization to address cross-team, system-wide issues?
• Where appropriate, are team barriers posted on the wall of the R&D lead's office? Can these barriers be quantified as lost money, time to market, quality, or customer leads?
• Is a team or organization one of the few that offers a career path that aligns with the team's collective goals? Answer "No" if programming or architectural work comes at the expense of tests, automated tests, or user documentation.
• Has the team or organization been recognized as the best organization or industry leader by professional publications or other independent sources?
• Are you creating a learning organization?

Source: www.sohu.com