译者导读：

文章说明了产品待办列表并不能代替Sprint待办列表，解释了Sprint待办列表的必要性，并阐述了实施Sprint待办列表时可结合看板一起使用。

¶7 Scrum团队制定了¶55 产品待办列表。团队处于¶24 Sprint 计划并且准备对目前的¶46 Sprint 在¶75 生产阶段开始计划。产品待办列表不会定义怎么样达成解决方案或实现方案，或怎么样部署解决方案。 

产品待办列表代表了¶14 开发团队开发的某项产品更新的的¶63 启用规范，一个产品待办列表明确了要建立什么但不会指明怎么样建立。

Scrum 帮助团队管理风险。PBI能提供Scrum团队足够的信息来评估外部风险。然而，它无法洞察到复杂开发过程中的相关风险。开发工作本质上具有自发性。PBIs 以业务（终端用户和市场）术语描述交付成果，而开发团队则以生产术语进行工作和评估。

两个重要的风险管理的因素是可行性和时间。为了理解并减少风险，你必须掌握PBI的足够细节，有信心保证技术上可行，且能在生产阶段内达到完成状态（参见¶82 完成的定义）。即使这样，前期你也不能对可行性抱有100%的信心，尽管你能在Sprint 计划阶段避免大部分的风险，你需要接受生产周期中自然涌现的新需求。我们不想将其置于次要地位或视作二等公民。但这些需求本身并不构成独立的PBI。

你还可以通过将功能全程推进至实现阶段来降低风险；事实上，优秀的¶11 产品负责人可能会为团队提供功能上可用的原型。然而，在仅考虑商业标准而忽视工程、开发和部署成本后，就将PBI推进至生产阶段，风险是极高的。如果该首要PBI自己占用整个生产阶段，那么在Sprint阶段将无法完成其他任何事。

你可以着手处理某个PBI的工作，一旦发现它会危及Sprint 交付就把它搁置。

但是，工作量在进行中可能会无限膨胀。粗粒度估算既不精确、不可靠，又难以预测：你需要¶58 小条目来进行估算。

通过改变看待PBI的方式，你能提升开发效率。PBI包含一系列互补任务，这些任务依赖团队协作与并行开发。团队可自主组织启动工作，但仍需一些方向。如何防止团队成员只专注于完成PBI所需的五项任务中的一项？若团队计划对PBI蜂拥而上（参见Swarming: One-Piece Continuous Flow），他们最好事先进行充分讨论。

因此，要将PBI拆分成工作条目，并且整合成一个计划，叫做¶72 Sprint待办列表。每一个工作条目就是一个Sprint待办列表（SBI）。通常每个Sprint待办列表条目不应超过单个开发成员在单个工作日内可完成的量。

开发团队通常将工作用任务表示，但团队也可将其用内部工件代替，或通过任何其他分解方式呈现，只要这种分解能让开发团队确信能通过这些工作项达成其¶71 Sprint目标。团队将所有必须在Sprint期间完成的工作项整合为一个计划，即Sprint待办列表。Sprint待办列表会成为开发团队对产品增量开发的视图。

设计过程（无论是在Sprint计划阶段还是Sprint期间）能为工作提供洞察。设计流程可降低风险，如：意识到未知的额外工作的成本，或者在Sprint后期因发现大量潜在工作而延误交付，设计能明确产品待办事项，并揭示未知工作。

团队可在生产阶段将SBIs作为进度衡量单位。¶43 Sprint燃尽图以Sprint待办事项中工作项的粒度反映进度。这种粒度支持快速反馈，它也能通过创建小的条目来评估提高评估精度。

SBI的集合是动态的，并且随着我们对产品的深入了解而变化。SBI可能作为新发现的工作出现（例如需要更多设计和开发），也可能在生产过程中消失。因此，应在¶29 每日站会中讨论他们并重新规划Sprint。团队应在新的SBI出现时进行评估，并为每个SBI分配¶60 评估点。团队也应该相应的更新Sprint燃尽图。

开发团队集体负责Sprint待办列表中的所有SBIs。常见做法是将SBIs写在便签纸上，贴于¶44 Scrum看板以直观看到工作进展。便签内容应精简至最低限度：SBI的文字描述仅需提醒开发团队迄今累积的工作计划的成果。另一常见做法是在便签上写上评估点数，以便当团队将工作项移至“完成”状态时，更容易更新Sprint燃尽图。团队运用便签的创意方式多种多样（如：颜色区分、旋转便签、添加标记等），这些方法均能让Sprint待办列表有更好的可视化呈现。使用上无需特别的规范：开发团队应自主决定并寻找最优实践方案。

译者：Sara Wu
 校对：雷慧雯 

点击回顾第一册 Scrum模式语言合集
Tips：以上带符号黑体是模式语言。