在Scrum中，谁创建产品待办事项？产品负责人与团队角色对比

这个问题比表面上看起来要复杂得多。首先，你可以说产品待办事项待办事项可以包括用例、史诗、用户故事，甚至缺陷，或产品待办事项中的时间盒研究任务。

在最简单的定义中，Scrum产品待办事项只是项目中需要完成的所有产品待办事项（PBIs）的列表。它取代了传统的需求规格说明文档。PBIs反映了客户或利益相关者的需求。一种常见的捕捉最终用户需求的方法是将PBIs写成用户故事.

谁负责维护产品待办事项？

产品负责人（PO）代表利益相关者“拥有”产品待办事项，并主要负责创建它。产品负责人无需亲自创建待办事项——他或她可以委托给开发团队和/或Scrum 主管来帮助定义和估算待办事项。产品负责人负责产品待办事项的创建和维护。因此，产品负责人还负责监督待办事项细化过程。

产品待办事项对应于你的项目路线图——团队计划交付的计划。团队定义之后，他们会确定哪些功能和需求需要优先开发。产品待办事项还充当一个存储库，包含团队需要跟踪和共享的所有信息。

如前所述，PBIs反映了客户或利益相关者的需求。一种常见的捕捉最终用户需求的方法是将PBIs写成用户故事。然而，PBIs还可以包括用例、史诗、用户故事、缺陷，或产品待办事项中的时间盒研究任务。实际上，产品待办事项中的各项内容并不都在同一详细程度上，如下图所示：

详细的产品待办事项

我们计划近期开展工作的PBIs应位于待办事项的顶部，规模较小，且高度详细，以便能在短时间内进行处理冲刺我们短期内不会处理的PBIs应放在待办事项列表的底部——规模更大，细节更少。这样没问题；我们短期内并不打算处理这些事项。

当我们接近处理较大的PBIs（如史诗级任务）时，我们会将其分解为一系列较小的、适合冲刺的用户故事。这需要及时完成。如果过早细化，可能会浪费时间去研究那些最终不会被实现的细节。如果拖延太久，就会阻碍PBIs流入冲刺阶段，从而拖慢团队进度。我们需要在合适的时间找到恰当的平衡。

敏捷优先级产品待办事项列表

产品负责人（PO）代表利益相关者“拥有”产品待办事项列表，主要负责创建和维护它。PO无需亲自创建每个待办事项——他或她可以邀请开发团队和/或Scrum Master参与，协助定义和估算事项。PO负责监督整个待办事项列表的细化过程。

因此，回答这个问题：产品负责人拥有产品待办事项列表，但无需创建每个待办事项。通常，产品负责人可根据高层次需求或用户目标创建大型PBIs，然后委派团队协助将其分解为用户故事。这些较小的故事——适合放在待办事项列表顶部，并满足“就绪”（通常在就绪定义）——随后被移入冲刺待办事项列表.