谁在Scrum中创建产品Backlog项目或用户故事？
原创
谁在Scrum中创建产品Backlog项目或用户故事？ 这个问题比听起来要复杂一些。首先，您可能会说 产品Backlog Item 可以包括: 用例 (use cases)，史诗 (epics)，用户故事 (user stories)，甚至是错误 (bugs)，或者是产品积压 (Product Backlog) 中的时间盒 (timeboxed) 研究任务 (research tasks)。
在最简单的定义中，Scrum Product Backlog只是需要在项目中完成的所有待办事项（PBI）的列表。它取代了传统的需求规范工件。Prodcut Backlog Items (PBIs) 反映了客户或利益相关者的需求。结合最终用户需求的常用方法 是以用户故事的形式 编写 PBI 。
谁负责维护产品积压 (product backlog)？
产品负责人（PO）代表利益相关者“拥有”产品待办事项，并主要负责创建产品 。PO没有必要亲自创建积压 - 他或她可以指示开发团队和/或Scrum Master帮助他/她定义积压项目并估算它们。PO负责产品积压的创建和维护。因此，PO还监督积压细化过程。
产品积压对应于您的项目计划，即团队计划提供的路线图。在团队定义之后，团队会优先列出要构建的功能和要求。产品待办事项还提供了一个存储库，其中包含团队需要跟踪和共享的所有信息。
产品Backlog项目= 用户故事 ？
如上所述，PBI反映了客户或利益相关者的需求。结合最终用户需求的常用方法 是以用户故事的形式 编写 PBI 。但是，PBI可以包括用例 (use case)，史诗 (epic)， 用户故事 (user story) ，甚至是错误，也可以是产品积压中的时间盒研究任务。实际上，并非产品待办事项中的所有项目都会同时处于相同的详细级别，如下图所示：
产品Backlog改进 （ Backlog Refinement ）
我们计划很快开展工作的PBI应该接近积压的顶部，尺寸很小，而且非常详细，以便它们可以在短期冲刺中工作。我们将在一段时间内不工作的PBI应该在积压的底部，更大，更不详细。没关系; 我们不打算很快就在这些PBI上工作。
随着我们越来越接近制作更大的PBI，例如史诗，我们将把这个故事分解成一系列较小的，冲刺准备的故事。这应该以及时的方式进行。如果我们过早改进，我们可能会花费大量时间来弄清楚细节，但最终却没有实现故事。如果我们等待太久，我们将阻止PBI流入冲刺并使团队放慢速度。我们需要及时找到适当的平衡。
谁负责提炼PBI？
产品负责人（PO）代表利益相关者“拥有”产品待办事项，并主要负责创建产品。PO没有必要亲自创建积压 - 他或她可以指示开发团队和/或Scrum Master帮助他/她定义积压项目并估算它们。PO负责产品积压的创建和维护。因此，PO还监督积压细化过程。
因此，回答问题，拥有产品积压的产品所有者，但产品没有必要创建每个积压项目。通常，产品所有者可能会根据高级别要求或用户目标创建大型PBI，然后团队成员将帮助产品所有者将大型项目分解为用户故事，因为它会作为一些“sprintable”移动到积压的顶部用户故事。这些Sprintable用户故事通常在“Ready的定义”下 转移到Sprint Backlog 。
与积压 (Backlog) 相关的Scrum文章
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 [email protected] 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 [email protected] 删除。