产品待办列表是什么
产品待办列表对应的英文是project backlog，也有翻译为“产品待办事项列表”，是指为开发完善产品而待办的事项列表。
在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自由文档许可证下修改和再使用。]