Scrum剧本

敏捷快速入门指南 《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。 Scrum主题 产品列表梳理会议快速入门指南 每日站会快速入门指南 Sprint规划快速入门指南 Sprint评审快速入门指南 Sprint回顾快速入门指南 其他主题： 故事拆分快速入门指南 编写清晰明确的用户故事快速入门指南 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的计划 根据我们的速度预测和大小确定，这是一个现实的计划吗？ 如果对上一个问题的回答为”否”，则拆分故事，或交换优先级相近的小故事，直到团队对计划充满信心为止 注意：另请参阅多年前我写的产品列表梳理