前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >谁在S​​crum中创建产品Backlog项目或用户故事?

谁在S​​crum中创建产品Backlog项目或用户故事?

原创
作者头像
Warren2Lynch
修改2018-12-14 10:09:31
1.5K0
修改2018-12-14 10:09:31
举报
文章被收录于专栏:UML

谁在S​​crum中创建产品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改进

产品Backlog改进Backlog Refinement

我们计划很快开展工作的PBI应该接近积压的顶部,尺寸很小,而且非常详细,以便它们可以在短期冲刺中工作。我们将在一段时间内不工作的PBI应该在积压的底部,更大,更不详细。没关系; 我们不打算很快就在这些PBI上工作。

随着我们越来越接近制作更大的PBI,例如史诗,我们将把这个故事分解成一系列较小的,冲刺准备的故事。这应该以及时的方式进行。如果我们过早改进,我们可能会花费大量时间来弄清楚细节,但最终却没有实现故事。如果我们等待太久,我们将阻止PBI流入冲刺并使团队放慢速度。我们需要及时找到适当的平衡。

产品待办事项列表梳理
产品待办事项列表梳理

谁负责提炼PBI?

产品负责人(PO)代表利益相关者“拥有”产品待办事项,并主要负责创建产品。PO没有必要亲自创建积压 - 他或她可以指示开发团队和/或Scrum Master帮助他/她定义积压项目并估算它们。PO负责产品积压的创建和维护。因此,PO还监督积压细化过程。

因此,回答问题,拥有产品积压的产品所有者,但产品没有必要创建每个积压项目。通常,产品所有者可能会根据高级别要求或用户目标创建大型PBI,然后团队成员将帮助产品所有者将大型项目分解为用户故事,因为它会作为一些“sprintable”移动到积压的顶部用户故事。这些Sprintable用户故事通常在“Ready的定义”下转移到Sprint Backlog

与积压 (Backlog) 相关的Scrum文章

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档