排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的
信息就能做出更准确的估算。优先级越低)细节信息越少。开发团队在接下来的 中将要
进行开发的产品待办事项列表条目是细粒度的)已经被分解过)因此)任何 一个条目在 的
时间盒内都可以被“完成”。开发团队在一个 中可以“完 成”的产品待办事项列表条目被认
为是“准备好的”或者“可执行的”)能在 计 划会议中被选择。
随着产品的使用、价值的获取以及市场的反馈)产品待办事项列表变成了更大、更详 尽的列表。
因为需求永远不会停止改变)所以产品待办事项列表是个不断更新的工件。业 务需求、市场形
势和技术的变化都会引起产品待办事项列表的变化。
若干个 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列
表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。
通过产品 地梳理来增添细节、估算和排序。这是一个持续不断 的过程)产品负责人和
开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候)条目会被评
审和修改。然而)产品负责人可以随时更新产品代办事项列表条目或酌情决定。
梳理在 中是一项兼职活动)在产品负责人和开发团队之间展开。通常)开发 团队有自行
优化的领域知识。然而)何时如何完成优化是 团队的决定。优化通常占用不超过开发团
队 ,-的时间。
开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但
是)最后的估算是由执行工作的人来决定的。
监控向目标前进的进度
在任何时间)达成目标的剩余工作量是可以被累计的。产品负责人至少在每个 评审的时
候追踪剩余工作总量。产品负责人把这个数量与之前 评审时的剩余工作 量做比较)来评
估在希望的时间点完成预计工作达成目标的进度。这份信息对所有的干系人都透明。
不考虑已经花在产品代办事项列表条目上的工作时间。我们只关心剩余工作和日期这两
个变量。
各种趋势燃尽图、燃烧图和其他计划实践都能用来预测进度。它们已经被证实有用。 然而)这
并不能代替经验主义的重要性。在复杂的环境下)将要发生的东西是未知的)只有已经发生的事
情才能用来做前瞻式的决策。
SPRINT BACKLOG
代办事项列表是一组为当前 选出的产品代办事项列表条目)外加交付 产品增量和
实现 目标的计划。代办事项列表是开发团队对于哪些功能要包 含在下个增量中)
以及交付那些功能所需工作的预计。
代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行
的工作。代办事项列表使开发团队确定的、达到 目标所需的工 作清晰可见。