产品待办列表在Scrum流程中扮演关键角色，由产品负责人管理并根据优先级排序。团队通过Sprint目标监控进度，持续细化和估算任务。产品待办列表动态演变，反映产品需求变化，是所有开发工作的源清单。
Product Backlog (产品待办列表) 是所有你所产品的需要 (Product requirements) 以及产品需求变化 (new product requirements) 的唯一来源排序列表。产品拥有者 (product owner) 是负责该等内容，产品待办事项列表中的优先及可用性称为 Product Backlog的优先级 (priority order)。
Product Backlog 是一个不断改进的列表，初始版本只列出了最初步和众所周知的需求（没有必要詳盡理解）。产品待办列表会根据产品和开发环境的变化而演变。Backlog 是动态的，它经常变化以迎合产品合理、有竞争力和更有价值的必要条件。只要产品存在，产品待办列表就存在。
产品待办列表列出了对未来版本进行的所有功能、用例、用户故事、改进和错误修复。产品待办事项列表条目包含描述、顺序和估计的特征。
产品待办列表项(PBI) 通常按价值、风险、优先级和必要性进行排序。它是一个从最高到最低优先级的序列。需要立即开发顶部的产品待办事项列表条目。排名越高，产品待办事项列表条目越紧迫，您越需要更仔细考虑，並对其价值的看法也应越一致。
Scrum 产品待办列表
Product Backlog 中排名较高的项目比排名较低的项目更清晰、更具体。你就可以基于更清晰的内容和更详细的信息对这些项目进行更准确的估计。换句话说，产品待办列表中项目的优先级越低，它们的细节就越少。
开发团队将在Sprint中开发的产品 backlog 项目是细粒度的，并且已经分解，因此等项都可以在 Sprint 的时间框中 (timebox) 完成” 。开发团队可以在 Sprint 中“完成”的产品待办事项被认为满足定义就绪的 (Definition of ready)，並可以放上Sprint planning meeting 。
Scrum 流程
随着产品的部署、价值的获取和市场的反馈，产品待办列表变成了一个更大、更详细的清单。因为需求永远不会停止变化，所以产品待办列表是一个不断更新的 artifact。业务需求、市场条件和技术的变化可能会导致产品积压的变化。
几个Scrum 团队经常一起工作来开发一个产品。但是，我们只需有一个产品待办事项来描述下一个产品开发工作 (development work)。然后，我们也需要使用产品待办列表项不断进行分类及更新的其属性及优先次序。
通过整理产品待办列表来添加详细信息、估计和排序。这是一个持续的过程，产品所有者 (product owner) 和开发团队 (development team) 合作讨论产品代表列表条目的详细信息。条目在产品待办事项列表中排序时进行审查和修改。但是，产品负责人可以随时更新产品待办列表的项目或做出适当的调整。
Product Backlog Grooming是 Sprint 中的一项持续活动，而不是一个时间框事件，与产品所有者和开发团队一起。通常，开发团队拥有可以完善自己的领域知识。但是，何时以及如何完成优化是Scrum团队的决定。产品待办列表细化 (backlog refinement) 通常不超过开发团队时间的 10%。
产品待办列表细化会议
开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的决定。但是，最终估计由执行工作的人决定。
使用 Sprint 目标监控进度
在任何时候，为实现目标 (Sprint Goal) 而剩余的工作量都可以从已完成的工作中累计扣除。产品负责人至少为每个Sprint 评审 (Sprint Review) 跟踪剩余的工作总量。产品负责人将此数量与之前 Sprint 评审的剩余工作量进行比较，以评估在所需时间点实现的预期工作的进度。这些信息对所有利益相关者都是透明的。
Scrum 不考虑在产品待办列表中的项目上花费的时间。我们只关心剩余的工作和日期变量。
可以使用各种图表或燃尽图 (Burndown Chart)以及其他规划实践来预测进度。它们已被证明是有用的。然而，这并不能取代经验主义的重要性。在复杂的环境中，将要发生的事情是未知的，只有已经发生的事情才能做出前瞻性的决定。
Scrum Sprint 进度
扫一扫
2600
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
