Scrum Master 可能会遇到的场景
场景1
场景描述
在一个Sprint的过程中，公司的CEO出现在你面前并告诉你：我们的一个客户提出了一个特殊的需求，如果我们可以完成这个需求，那么便可以赚到一百万美金。
要点分析
无论公司CEO权利再大，在Scrum面前他也只是一名Stakeholder。Stakeholder不能直接干预Scrum团队的工作。Stakeholder的需求应该由Product Owner出面应付，而不应直接由Scrum Master和Team来处理。
场景2
场景描述
Product Owner说他没有时间参加Sprint计划会议，但是他并不介意Team在他缺席的情况下继续完成这些工作。
要点分析
Product Owner是对产品负责的人，而且他需要提供Product Backlog的优先级，因此Team有权要求他参加会议。如果Product Owner是偶然性的缺席，那么可以推迟会议；如果他经常缺席，那么最好换一名人选。
场景3
场景描述
在一次Sprint过程中，一名团队成员的经理过来和你协商，说她需要将这名成员从项目中抽调几天去完成另一项工作。
要点分析
Product Owner才是唯一能对团队工作造成影响的人（例如取消Sprint），而这位经理则不应在Sprint过程中干涉Scrum团队的工作。而且，Scrum Master应尽力去保护（Shield）整个Team。团队组成可以在各个Sprint之间发生改变。
场景4
场景描述
目前，这个Sprint已经时间过半，而团队的进度已经落后了。你觉得看起来似乎没有任何办法在这个Sprint中完成当初所承诺的工作。
要点分析
“看起来”和“似乎”是Scrum Master的个人观点，而Team才是工作的执行者，因此应该向团队确定是否真的无法赶上进度。如果Sprint真的不能完成，别忘了我们有“应急手段”（Emergency Procedure）。
场景5
场景描述
一名团队成员看起来不太高兴，他似乎非常心不在焉，并且已经落后于他所承诺完成的任务量了。
要点分析
这是一种非常棘手的情况，Scrum并不能处理这种问题，因此用常识和情理来解决吧！
场景6
场景描述
有一位团队成员告诉你Product Owner刚刚要求她在当前的Sprint中加一个工作项，而目前该Sprint已经进展了三分之一。
要点分析
Scrum团队的需求沟通方式是Product Owner对全体团队成员，或Product Owner仅对Scrum Master，而不应该是Product Owner单单对某一个团队成员。能否完成额外任务需要由整个团队来决定，而不是一个人。此外，Scrum Master应尽量保证Sprint中需求范围的确定性，因此Scrum Master要学会对Product Owner说“不”。
场景7
场景描述
Team中的一位成员说他认为Retrospective会议是浪费时间，而其他几位成员也嘟囔着表示赞同，甚至有人建议立刻停止Retrospective会议。
要点分析
试着给每个Retrospective会议做一个小的评估，来让它变得更有效且有趣。
场景8
场景描述
Team看起来已经疲惫不堪了，他们几乎每个工作日都工作到很晚，甚至为了完成Sprint的目标，他们每周六还要来加班。你听到一些大家关于Scrum的评论，例如Scrum糟糕透了，它强迫我们工作的太辛苦了之类的。
要点分析
我们不应该通过加班来掩盖项目中所暴露的问题以及Scrum带来的风险信号。
场景9
场景描述
三个Sprint以来，Team在每个Sprint中都遇到了一些问题，并且每次都强制缩减了Sprint的需求范围。
要点分析
尽管这三次缩减Sprint需求范围的情况可能都由同一个原因造成，但更可能的情况是团队在这三次中都遇到了不同的问题。
场景10
场景描述
有一位团队成员并不愿意和其他人坐在一起，而是更愿意拥有一个独立的工作环境。
要点分析
每个人可能都有自己的工作方式，找出原因并解决问题。记住一句话，强扭的瓜不甜。选择一种最好的解决方案，并让Team能够顺利工作。
场景11
场景描述
Team和Product Owner无法在“完成”的定义上达成一致意见。
要点分析
试着将完成的定义留给Team。如果Product Owner对Team的工作成果并不满意，那么再遵从Product Owner的要求。
场景12
场景描述
一位团队成员拒绝用一种更简单的方法来达成Sprint的目标，因为他的生产线经理希望他用一种更高级的解决方案，以便之后能够将现有产品迁移到某个特定软件的更高版本。
要点分析
有的时候我们必须遵从某些特定的生产规定。试着与生产线经理进行协商，如果该规定为强制性的，那我们也只能妥协，但整个Scrum团队都应该知晓这样做的结果和风险，并针对可能遇到的问题制定解决方案。
#