Scrum完整剧本
敏捷快速入门指南
《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。
Scrum主题
其他主题：
Product Backlog Refinement
简介：产品列表梳理会议（也称为需求梳理）不是Scrum指南中定义的活动。然而，产品列表梳理的实践在Scrum团队中是非常普遍，以至于一些从业者认为这是普遍接受的Scrum实践。
定义
产品列表梳理会议是为即将到来的（如接下来的1-2个）迭代（Sprint）准备用户故事的一个持续过程。产品列表梳理有两个主要方面：
- 由产品经理和产品负责人领导的，需求功能不断定义、完善、澄清以及重新确定顺序；
- 在Sprint开始之前进行的一次协作会议，以评估新信息，确保准备开发下一组故事。
频率
- 每个Sprint一次（通常是Sprint中，下一个Sprint开始前的1-5天不等）
注意：某些团队选择每个Sprint进行多次"梳理"会话。如2周的SPrint，可能一周梳理1次。
持续时间
团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时，团队更有可能在相当短的时间内完成产品列表梳理。（另请参见编写清晰明确的用户故事快速入门指南。）
参与者、输入、输出
- 参与者 – 产品负责人，ScrumMaster，开发团队
- 输入 – 主要输入是为即将到来的Sprint预测的用户故事，这些可能是后续Sprint的不错选择。处于就绪状态的用户故事要多于下一个Sprint可能会有所帮助。因此，如果团队确定依赖性，并有了影响多个故事的优先级或工作量的新信息，那么就可以灵活处理。
- 输出 – 整个团队达成共识，就一组排好序、清晰定义且独立的用户故事达成共识。
活动
产品列表梳理期间的活动通常包括：
- 查看从当前Sprint中学到的新信息
- 讨论最快速度、可能速度和最差速度
- 是否对当前的Sprint进度进行检查 - 我们是否认为我们将完成Sprint期间的所有工作？
- 在回答这个问题时，请牢记可持续的步伐
- 对于团队来说，在Sprint中去现实地评估事情，比等到Sprint结束后再进行任何变更，要好的多（香不香？）。
- 查看并澄清即将发布的用户故事
- 讨论并同意验收标准（Acceptance Criteria），以确认双方的理解。以及确认估算大小和拆分太大的故事
- 提醒：任何故事，如果团队在一个SPrint内无法完成4个，那么就是太大了。
- 同意下一个Sprint的计划
- 根据我们的速度预测和大小确定，这是一个现实的计划吗？
- 如果对上一个问题的回答为"否"，则拆分故事，或交换优先级相近的小故事，直到团队对计划充满信心为止
注意：另请参阅多年前我写的产品列表梳理
Daily Scrum
定义
每日Scrum（又称每日站会）是开发团队通过简短的、有针对性的对话来确保他们每天保持一致。每日Scrum期间发生的主要事情：
- 分享知识
- 找出帮助其他团队成员的机会
- 识别依赖性、风险
- 同意删除障碍的后续步骤
频率
每天一次（一般SPrint第一天除外，因为已经有了计划会）；每天同一时间、同一地点，会降低复杂度。
持续时间
每日Scrum的持续时间不得超过15分钟。
参与者、输入、输出
- 参与者 – 开发团队，ScrumMaster（或其他主持人），产品负责人
- 输入 – 主要输入是自上次"每日Scrum"以来的任何工作。其他潜在的输入包括在测试过程中可能出现的任何异常情况、优先级的更改，或其他可能影响Sprint计划的任何情况
- 输出 – 团队成员之间在以下方面达成共识，例如何解决已出现的任何障碍，以及如何在接下来的24小时内最有效地合作以将正在进行的工作项移至已完成方面达成共识
注意： 与会者按重要性顺序列出：每日Scrum用于开发团队，因此会议属于团队的。Scrum Master通常作为主持人出现。但是，团队中的不同成员轮流担任主持人也很常见（不一定只有ScrumMaster来主持）。对于产品负责人而言，阐明可能出现的任何与产品相关的问题也可能会有帮助。