一些最佳做法，即将推出的产品列表

可采取的措施清单是一个产品

即将推出的产品列表对应的英文是project backlog，也译作“产品-do名单”，是问题为无害的产品和即将开发的列表。

在Scrum Guide中，产品待办列表是一个排序的列表，包括全部产品须要的东西，也是产品需求变动的唯一来源。

产品负责人负责产品待办事项列表的内容、可用性和优先级。产品待办事项列表永远是不全然的，最初的版本号仅仅列出最初始的和众所周知的需求。产品待办事项列表依据产品和开发环境的变化而演进。待办事项列表是动态的，它常常发生变化以识别使产品合理、有竞争力和实用所必需的东西。仅仅要产品存在。产品待办事项列表就存在。

产品待办事项列表列出了全部的特性、功能、需求、改进方法和修复等对未来公布产品进行的改变。

产品待办事项列表条目包括描写叙述、次序和估算的特征。

产品待办列表里有什么？

产品待办列表的另外一个翻译产品待办事项列表显示产品待办列表里应当包括待办事项。

待办事项包括全部的特性、功能、需求、改进方法和修复等对未来公布产品进行的改变。

常见的待办事项是以用户故事形式来表达的。

怎样维护产品待办列表？

在Scrum Guide中，产品待办列表通常以价值、风险、优先级和必须性排序。

排在顶部的产品待办列表条目须要马上进行开发。

排序越高，产品待办列表条目越紧急，就越须要细致斟酌。而且对其价值的意见越一致。排序越高的产品待办列表条目比排序低的更清晰、更详细。

依据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低。细节信息越少。

开发团队在接下来的Sprint 中将要进行开发的产品待办事项列表条目是细粒度的，已经被分解过。因此，不论什么一个条目在 Sprint 的时间盒内都能够被“完毕”。开发团队在一个 Sprint 中能够“完毕”的产品待办列表条目被觉得是“准备好的”或者“可运行的”，能在 Sprint 计划会议中被选择。随着产品的使用、价值的获取以及市场的反馈。产品待办列表变成了更大、更详尽的列表。由于需求永远不会停止改变。所以产品待办列表是个不断更新的工件。

业务需求、市场形势和技术的变化都会引起产品待办列表的变化。

若干个 Scrum 团队经常会一起开发某个产品。但描写叙述下一步产品开发工作的产品待办列表仅仅能有一个。

那么这就须要使用对产品待办列表条目进行分组的属性。“产品代表事项列表优化（英文原文是grooming）”是增添细节、估算和排序条目的举动。这是一个持续不断的过程，产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表优化的时候。条目会被评审和改动。然而，产品负责人能够随时更新产品待办事项列表条目或酌情决定。

单列表的产品待办列表有什么困难？

从以上文字能够判断，Scrum Guide所说的产品待办列表是一张列表。通过不断维护。排在顶部的待办事项得到了分析，并拆分到足够小的粒度，以便在一个Sprint中进行开发。这样做法有例如以下的两大弊端：

1，早先的一个待办事项可能分解成多个待办事项，其关联信息难以维护

2，早先收集的信息在优化和细化过程中可能在多次传递后失真

树形的产品待办列表更具表现力

人们为了克服单列表的不足，採用了树形的产品待办列表，常见形态例如以下：

       1原始需求或者史诗故事A

                     1.1用户故事或者用例A1

                     1.2用户故事或者用例A2

       2原始需求或者史诗故事B

                     2.1用户故事或者用例B1

                     2.2用户故事或者用例B1

                         2.2.1 更细的用户故事B11

                         2.2.2 更细的用户故事B12

这样，原始的信息和关联关系都得到了维护。

第二种方式是有关联关系的多列表，形式例如以下

第一级列表（比方原始需求，史诗故事）	第二级列表（比方用户故事，需求用例等）	第三级列表（比方界面细节）
epic1	userstory1 userstory2 userstory3	相应于userstory1的细节 相应于userstory2的细节 相应于userstory3的细节
epic2	userstory4 userstory5 userstory6	...
......	...

博客中表格改动不易，一般的。在敏捷开发环境下，不使用第三级列表。

显然的，关联关系的多列表也能够转换成树形结构。如今不少工具能够帮助展现不同的形态以方便各人的习惯

长期运维的产品待办列表不再仅仅包含待办事项

对于已经完毕的待办事项怎样处理？ 常见有两种做法：

1，从产品待办列表中移除，可是不能真的扔掉，为了产品的长期运维，将其转移组织到反映产品最新需求的文档中，常见用wiki作为载体。 

2，保留在产品待办列表中，进行状态和版本号管理。

第2种做法无须进行转移，利用条目化管理工具（比方VSTS，JIRA，Redmine。Polarion，Mantis，SharePoint等等）能方便的管理好状态和版本号。

当某已经完毕事项须要改动增强升级时，仅仅需检索到原条目，然后进行改动，然后将其公布目标版本号设为最新的版本号。较之第1种方法，无需搬移，而第1种方法的话。遇到改动增强升级时。先从文档中检索到最新情况，然后依据最新情况撰写待办事项进入到产品待办列表。做完之后。从产品待办列表中再搬移回文档。

随着工具的发展。第2种做法渐渐成为多数的选择，在这样的情况下。产品待办列表的字面意思就不再恰当。或许改名为产品需求列表更为合适。或者说产品待办列表是产品需求列表的一部分，对产品需求列表设立一个过滤器，查询未完毕的待办事项就得到了“产品待办列表”。

參考资料 

1，Scrum Guide 中文版  https://www.scrum.org/Scrum-Guide  

[本页面的文字同意在知识共享 署名-同样方式共享 3.0协议和GNU自由文档许可证下改动和再使用。]