一个普通的ScrumMaster能够同时应付2-3个团队。如果你把你的角色局限在组织会议、确保时间盒和响应组员提出来的障碍，并对此感到满意的话，你可以只用部分时间来曾担ScrumMaster的角色。在此情况下，团队的绩效可能还是会超过组织的预期，可能也不会有很糟糕的事情发生。但是如果你展望一个能在转型的组织里做出前人难以想象成就的团队，你需要考虑成为一个很棒的ScrumMaster。很棒的ScrumMaster一次只支持一个团队。我们推荐一个7人左右的团队能有一个专职的ScrumMaster，特别是在团队的初始阶段。

如果你还未发现有很多的工作要做，仔细看一下你的产品负责人、你的团队、你团队的工程实践和他们所在的组织。尽管没有对每人都适用的药方，这份检查清单，包含了一些经常被ScrumMaster忽视的事情。

1.我的产品负责人做得怎样？

☐ 产品待办列表是根据产品负责人最新的想法优先级排序的吗？

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（INVEST） 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.

☐ 你能通过给大家打印件来帮助传播待办列表包含的信息吗？

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?

☐ 所有的利益相关人（包括团队）都知道是否发布计划还和团队现有的速率符合吗？你可以尝试在每个Sprint评审会议上在条目被确认“完成”后向所有人展示产品发布燃尽图。这会帮助我们更早地发现范围和时间的漂移。

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 2 Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery of scope/schedule drift.

☐ 你们的产品负责人会在Sprint评审后调整发布计划吗？少数能够准时交付充分测试过的产品的产品负责人会在每个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 re-plan the release every Sprint. This probably requires deferring some work for future releases as more important work is discovered.

2.我的团队做得怎样？

☐ 团队成员大多数时间处在流畅状态吗？这种状态的一些特征：

    • 明确的目标（对期望和规则是了解的，目标是可达到的、和团队的能力相匹配）

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

☐ 你尝试过用不同的形式和地点做Sprint回顾吗？

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

☐ 团队在Sprint中一直关注验收标准吗？也许你应该举行一个Sprint中的检查来重新看一下这个Sprint承诺条目的验收标准。现在列出的Sprint任务够吗？

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.

☐ Sprint任务反映团队实际在做的事情吗？

Does the Sprint taskboard reflect what the team is actually doing? Beware the “dark matter” of undisclosed tasks and tasks bigger than one day’s work. Tasks not related to Sprint commitments are impediments to those commitments.

☐ 团队是由3-9个具备混合技能的人员组成吗？

Does your team have 3-9 people with a sufficient mix of skills to build a potentially shippable product increment?

☐ 团队的任务估计和你们的任务板包含最新信息吗？

Is your team's taskboard up to date?

☐ 团队用于自管理的工件（任务板、Sprint燃尽图，等等）对团队可见吗？方便使用吗？

Are the team self-management artifacts visible to the team, convenient for the team to use?

☐ 这些工件有没有被保护以防止用于微观管理？团队外部的人对每日活动多余的审查会阻碍团队内部的透明性和自我管理。

Are these artifacts adequately protected from meddlers? Excess scrutiny of daily activity by people outside the team may impede team internal transparency and self-management.

☐ 团队成员自己选任务吗？

Do team members volunteer for tasks?

☐ 偿还技术负债的条目有没有包括在待办列表里？如果没有的话，团队有没有和产品负责人沟通？

Has the need for technical debt repayment been made explicit in the definition of done, gradually making the code a more pleasant place to work?

☐ 团队成员能否抛开各自的岗位定义，对约定工作的所有方面（测试、用户文档等）集体负责？

Are team members leaving their job titles at the door of the team room, collectively responsible for all aspects of agreed work (testing, user documentation, etc.)?

3.我们的工程实践做得怎样？

☐ 你们在开发中的系统有没有一个“按下测试”的按钮，从而每个人（同一团队或不同团队的）都能方便地检测到系统被破坏了？通常可以使用xUnit框架来实现。

Does your system in development have a "push to test" button allowing anyone (same team or different team) to conveniently detect when they've caused a regression failure (broken previously-working functionality)? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).

☐ 你们在自动化的端到端系统测试（或功能测试）与自动化的单元测试之间有适当的平衡吗？

Do you have an appropriate balance of automated end-to-end system tests (a.k.a. "functional tests") and automated unit tests?

☐ 团队用开发系统的同种语言来写系统功能测试和单元测试（而不是用只有部分团队知道如何维护的专用脚本语言或捕捉回放工具）吗？

Is the team writing both system tests and unit tests in the same language as the system they're developing? Collaboration is not enhanced by proprietary scripting languages or capture playback tools that only a subset of the team knows how to maintain.

☐ 你们团队已经发现在系统测试和单元测试之间存在有用的灰色区域吗？

Has your team discovered the useful gray area between system tests and unit tests ?

☐ 当有人引起回归失败时，是否有个持续集成服务器会在一小时甚至几分钟内自动发出警报？（Kent Beck说过，“每日构建只是弱者的水平”）

Does a continuous integration server automatically sound an alarm when someone causes a regression 7 failure? Can this feedback loop be reduced to hours or minutes? ("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 8 Big Up Front Design? Refactoring has a strict definition: changing internal structure without changing 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. Neglecting refactoring makes it hard to change the product in the future, especially since it’s hard to find good developers willing to work on bad code.

☐ 你们针对每个功能性产品待办条目的“完成”的定义（验收标准）包含了完整的自动化测试覆盖和重构吗？我从未看到过或听到过一个没有采用极限编程实践的超高效团队。

Does your definition of "done" for each Product Backlog Item include full automated test coverage and refactoring? Learning Test Driven Development (TDD) increases the probability of achieving this.

☐ 团队成员大多数时间都结对编程吗？结对编程显著地增加了代码的可维护性和减少了缺陷率。然而它挑战了开发人员之间的界限，有时候看起来花了更长时间（如果我们把数量放在质量之上的话）。以身作则与团队成员发起结对工作日，而不是迫使大家这么做。一些成员会开始喜欢这样工作。

Are team members pair programming most of the time? Pair programming may dramatically increase code maintainability and reduce bug rates. It challenges people's boundaries and sometimes seems to take longer (if we measure by lines of code rather than shippable functionality). Lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.

4.我们的组织做得怎样？

☐ 有适量的跨团队沟通吗？Scrum of Scrums只是其中的一种方式。

Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to achieve this, and rarely the best.

☐ 团队在需要跨越架构边界的情况下还能独立交付工作的特性吗？

Are teams independently able to produce working features, even spanning architectural boundaries?

☐ 你们的ScrumMasters聚在一起工作在组织的障碍列表上吗？

Are your ScrumMasters meeting with each other, working the organizational impediments list?

☐ 在适当的时候，组织的障碍有被贴在开发总监办公室的墙上吗？这些障碍带来的浪费能被量化为钱、失去的进入市场的时间、失去的质量或者失去的客户机会吗？（但是记得Ken Schwaber的发现：“一个不存在的ScrumMaster是个没用的 ScrumMaster。”）

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 learn from Ken Schwaber's mistakes: "A dead ScrumMaster is a useless ScrumMaster." )

☐ 你们组织是为数不多的能提供和团队集体目标一致的职业道路的组织吗？如果存在职业激励去做编码或架构工作，而牺牲测试、测试自动化或用户文档，回答“不是”!

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 creating a learning organization?