本书主要分为5个部分来讲，分别是 Scrum Master的角色、待办项的改进和估算、 Sprint计划、 每日站会、 回顾会；
以下是尽可能用易理解的语言来看待38个问题。

Sprint计划会议简要知识点

Sprint计划会议

Sprint计划

1. 背景知识点：

   产品经理在Sprint计划会议期间，会与团队成员共享待办事项中的高质量用户故事，之后团队成员将这些内容转化为更详细的用户故事并且进行评估；

   为了保证Sprint计划会议将需要团队成员对所属用户故事做出承诺，该用户故事是我负责的，我就应该把它做好的主人翁感。

   为了保证计划会议评估的高效率，什么样的用户故事会被允许进入到计划评估阶段呢？前文已经讲过，一般满足INVEST的用户故事才是好的用户故事，所以在进入到计划会议时，Scrum Master需要每周与产品经理针对产品待办事项中进行细化和评估会议，之后基本上细化和可评估的用户故事才满足已就绪的定义，方可进行评估和分配；

   Sprint计划会议通常分成两场：

   Sprint计划1：

   • 最有价值的用户故事排序；
   • 所涉及的必须的计划任务；

   Sprint计划2：

   • 针对具体用户故事，进行澄清；
   • 用户故事的分配；

   冲刺迭代任务配比：

   • 避免将80%以上的能力分配给新的任务：用户案例、技术任务、bug以及可能的峰值；
   • Bug、重构和研究需要定期关注，高效的Scrum团队至少有25%的能力分配到这些任务；

2. 问答：

• 问题18 Scrum master如何以使Scrum团队仅处理最有价值的用户故事的方式为Sprint计划做出贡献？

  问题意图：在Sprint计划中定义Sprint范围和目标理应是产品经理的职责所在，在如何使Scrum仅处理最有价值的用户故事，应该是需要Scrum Master的支持；

  可接受的回答：

  1. 在产品需求初期时，Scrum Master就参与其中；
  2. 确保Scrum团队与产品经理能够更好的理解待办事项细化的过程（用户故事’已就绪‘状态的定义来规范此流程）；
  3. 确保最终用户故事的创建是Scrum团队和产品一起努力的结果；（在理解一致的基础上，并且有主人翁感）。

  关键点: 尽早介入需求过程，已就绪定义，共同创建用户故事。

• 问题19 你使用什么指标评估用户故事的价值？

  问题意图： 收到用户故事，应该需要问问why，为什么要做这个需求，价值在哪？意义又在哪？有哪些度量方式来评估用户故事的价值和是否有必须进行评估？所以我们更应该站在用户的角度上去思考；

  可接受的回答：

  1. 客户的收入增加；
  2. 成本的减少；
  3. 客户满意度的提升；
  4. 增加了新产品的签约；
  5. 服务团队收到了客户积极的反馈；

  关键点： 意义，价值，成本，积极的反馈。

• 问题20 你如何以选择最有价值的用户故事，用这种方式促进用户故事的选择，而又不会推翻Scrum团队定义自己的承诺的特权？

  问题意图：如何权衡产品经理&Scrum团队关于用户故事优先级的选择；

  可接受的回答；

  1. Scrum团队成员尽早参与需求过程，并且与产品经理共同创建用户故事；这样在一致理解的基础上兼具主人翁意识；
  2. 如果团队挑剔用户故事（选择个人偏好的用户故事），需要更严格代办事项优先级和细化的过程；如每个冲刺版本都有一定时间给予到团队进行技术优化，产品经理&团队之间关于这个问题就会很少出现。

  关键点：尽早介入需求过程，共同创建，代办事项的优先级和细化过程。

• 问题21 你认为在常规sprint期间Scrum团队的容量是多少才足以进行重构？修订重要bug？探索新技术或新想法 ？

  问题意图：为了提高整理的效率，我们不断强调在Sprint期间，需要给团队预留一定的时间进行重构、bug和技术性的研究，那我们如何来分配这些时间呢？

  可接受的回答：

  除了冲刺优先级较多的新需求外，还有一些其他的技术问题需要解决：

  • 重构，为了还技术债；
  • bug修复，技术问题需要被修复；
  • 新技术&新想法，为了后续开发更有效率；

  有一个好的法则，15-10-5分配Scrum团队的容量来重构、修复和探索：

  1. 15%： 技术债；
  2. 10%： bug修复；
  3. 5%： 技术探索;

  个别冲刺会少有偏离，但是通常的这种做法能够马努大多数应用程序代码质量和维护的要求。

  关键点：15-10-5法则。

• 问题22 产品经理能否向scrum团队的成员分配用户故事或任务？

  问题意图： 产品经理是否可以指派任务？

  可接受的回答：

  1. 不可以，分派是伪敏捷，已经立即停止；
  2. Scrum团队是自组织团队，用户故事的分配和指派应该是团队自己的权利而不是产品经理的权利；

  关键点：自组织团队；

• 问题23 你怎样处理团队成员挑剔任务的行为？

  问题意图：如何团队管理团队挑剔者？
  

  可接受的回答：
  凡事是有原因的，为什么会挑剔任务，是因为习惯还是只是单纯不愿意承担？

  1. 培训：更多的培训可以帮助团队成员完成更多的任务；
  2. 引导：引导成员走出自己的舒适圈，以便他们能更乐意的选择不同类型的任务，而不是他们习惯的；
  3. 如果有团队成员抱怨其他人选择任务，Scrum Master应该及时介入。

  关键点：根本原因分析，培训，引导；

• 问题24 用户故事缺少最终的用户界面设计，但设计团队承诺在即将到来的sprint的第二天交付，团队的产品经理对此感到满意，并促使把此用户故事添加到sprint代办项。你对这个情景有什么看法？

  问题意图：如何处理这种破坏敏捷冲刺过程的流程？

  可接受的回复：
  是否应该把用户故事添加到Sprint待办事项，应该取决于团队的经验；

  • 类似情况只是偶尔出现：评估用户故事的优先级，如果优先级很高，团队同意后给予添加，但是需要与相关团队沟通，这次是个例外；
  • 经常性第二天会准时给出：建议谨慎添加，一定是用户故事细化或是在已就绪定义上出现了问题，找到根本原因，及时与产品经理&相关团队讨论如何改进；
  • 经常性第二天不会准时给出：不建议添加，在完全承诺后无法给出，会严重影响交付效果，可能会导致冲刺失败、士气低落，甚至会影响到整体敏捷过程的失败；

  关键点：根本原因分析，敏捷的破坏；

• 问题25 一名成员Scrum团队中不想参与Sprint计划会，并且认为开会是浪费时间。你怎样处理这种态度？

  问题意图：针对于团队中对敏捷有意见的同事，我们有什么方式进行处理？

  可接受的回答：不想参加Sprint计划会议，并且认为开会是浪费时间的行为，他们表现出一种消极的攻击性行为，这是个非常严重的问题，会影响团队的建设和绩效；

  该行为不能忽略也不能容忍，要产出一些循序渐进的方式：

  1. 私下交流：与团队成员私下交流，询问原因和想法，针对性的培训和教育；
  2. 公开讨论：可以把敏捷过程的重要性在一个或多个回顾会议中与大家共同讨论，让整个团队来影响他；
  3. 如果依然无法改变团队成员的态度，建议找他的职能经理进行沟通；
  4. 在没有改变的情况下，建议重新分配到其他项目组当中，迫使他们走出舒适圈，也保证敏捷团队的团队氛围和效率；

  关键点：循序渐进