什么是产品待办列表?

已发表: 2021-09-30

你有没有觉得你的团队一次又一次地犯同样的错误? 您认为事情进展不顺利,您需要进行一些更改以改进项目开发过程。

这里的产品待办事项可以帮助团队决定他们正在做什么以及他们想要关注什么。 它描述了团队将如何执行敏捷路线图中提出的想法。 在许多方面,它都是您的开发团队的一个巨大的待办事项清单。

项目可以是较大产品的一部分,并通过产品积压来管理它们。 产品 backlog 示例可以是客户实施项目,可以作为更大产品 backlog 的一部分交付。 或者,游戏制作工作室可以将每一代游戏视为具有设定期限(例如圣诞节前后)的单独项目。

Scrum 中的产品待办列表是什么?

在 Scrum 中,敏捷产品 backlog 是一个优先功能列表,其中包括所有产品功能的简要描述。 如果您正在处理一个项目,那么不需要花费很长时间来使用 Scrum 记录所有需求。 Scrum 团队及其产品负责人可以从包括他们能想到的敏捷 backlog 优先级的任何内容开始。

这种敏捷的产品积压对于第一个 sprint 来说绰绰有余。 随着有关产品及其客户的更多信息可用,Scrum 产品待办事项允许其扩展和适应。

在 Scrum 中,产品 backlog 是一个优先功能列表,其中包括所有产品功能的简要描述。 在使用 Scrum 时,不需要通过冗长的前期工作来记录所有需求来开始一个项目。

定制软件开发服务中,Scrum 团队及其产品负责人通常首先记下他们能想到的敏捷积压优先级的任何内容。 几乎总是,这种敏捷的产品积压对于第一个 sprint 来说绰绰有余。 随着有关产品及其客户的更多信息可用,Scrum 产品待办事项将被允许扩展和调整。

产品积压之旅如何开始?

首先是愿景或想法,然后是战略,要完成这个想法就需要路线图,在制定路线图之后是产品待办列表。 下面给出的指针显示了每个产品积压旅程术语的含义。

Product Backlog Journey

  • 产品战略是如何在高层次上实现公司目标的大纲
  • 产品路线图决定了要实施的计划
  • 产品待办事项包含生产专业产品所需的任务级别细节

产品待办列表和产品路线图有何不同?

两个关键的产品管理工具是产品路线图和产品待办列表。 每种仪器都有其自身的优点和缺点。 产品 backlog 不应与产品路线图混淆。 由于不同的原因,这两个活文档对于敏捷开发流程团队都很有用。 待办事项提供了战术开发细节,而路线图则集中在整体战略上。

Product Backlog and Product Roadmaps

产品积压管理需要各种任务和策略。 由于产品路线图经常更改,因此必须与产品待办列表紧密联系。 因此,必须定期对积压工作进行优先级排序(并重新确定优先级)以反映变化和发现。

产品待办事项包括史诗和用户故事、工作流程图、用户界面设计草图和模型,以及构建产品所需的其他出色工作。 它是一种战术工具,可指导开发团队的工作,并作为使用发布燃尽图等工具跟踪开发进度的基础。 下图总结了产品路线图和产品待办列表之间的主要区别。

产品路线图是一种战略性产品规划工具,它概述了产品在接下来的时间里将如何发展。 它建立了一种使命感,鼓励利益相关者参与,帮助获得资金,并更容易协调各种产品的开发和推出。

此外,应特别注意保持积压工作的结构化和可访问性。 产品 backlog 管理实践建议针对详细的、紧急的、估计的和优先的 (DEEP) 产品 backlog,其中具有最高优先级的项目包含最多的细节,并且随着优先级的增加,详细程度会降低。

大多数敏捷团队还参与产品待办事项梳理会议,用于细化和安排待办事项项目。 在这些会议期间,团队合作为几个 sprint 的用户故事提前计划。 敏捷 backlog 梳理会议可确保 backlog 顶部的用户故事有足够的细节让交付团队理解。

产品积压优先级技术

  • 产品待办事项梳理不是一次性事件,而是一个涉及产品所有者和开发团队的持续过程。 主题专业知识通常存在于开发团队中,他们可以对其进行改进。 另一方面,Scrum 团队决定何时以及如何完成优化。
  • 向产品待办列表中的项目添加细节、估计和订单的行为称为产品待办列表细化。 在每个 Sprint 中,都需要持续的 Product Backlog Refinement 来优化产品,以便它们为未来的 Sprint 做好准备。 产品待办事项的细化通常需要开发团队不超过 10% 的工作。
  • 产品待办列表顶部产品待办事项(最高优先级,最大价值)被分解,以便一旦待办事项被细化到适当的粒度级别,它们就适合一个 Sprint。

Product Backlog Prioritization Techniques

所有估算工作均由开发团队处理。 通过协助团队评估权衡,产品所有者可以对他们的决策产生影响。 另一方面,执行任务的人决定了最终的估计。

产品待办列表的好处

积压作为占位符

待办事项项目用作未来讨论实现目标的解决方案的占位符。 这意味着团队在将其添加到产品待办列表之前不需要有一个完全成熟的想法。 首次引入产品待办事项时,它只需要有足够的信息来提醒团队替代方案是什么。 当团队即将开始处理产品待办事项时,只需对其进行充分解释。

动态性质

产品 backlog 的动态特性允许团队跟踪他们对预期目标和潜在交付方法的了解。 当团队开始工作时,产品积压工作不必完成。 因此,他们可以从原始概念开始,并在获得经验时添加新的产品待办事项。

易于拆卸

仅仅因为产品积压中的某些东西并不意味着它必须交付。 如果项目对预期目标没有贡献,团队可以将其从积压工作中移除。 这意味着团队可以避免产生非增值的可交付成果,而是专注于做出真正​​有用的改变。

添加待办事项

团队可以使用产品待办列表来避免浪费时间根据有限的信息争论一个选项是否有价值。 当一个新想法出现时,团队可以添加一个产品待办事项作为提醒,以进一步调查该想法。 然后,团队可以优先考虑该想法以及其他项目,如果该想法被证明无法实现预期结果的进展,则删除产品积压项目。

Let's Talk

敏捷产品待办事项与 Sprint 待办事项 - 详细差异

简而言之,sprint backlog 就是团队的短期 sprint 计划。 敏捷中的产品待办事项是产品的长期计划,其中将愿景分类为为产品增加价值的有形可交付项目。 许多人认为 sprint backlog 是产品 backlog 的一个子集。 这是理想的; sprint backlog 完全由产品 backlog 中的项目组成。 此外,冲刺通常包括团队已承诺的其他工作以及在产品设计冲刺期间可以完成的任务

敏捷中的产品待办事项是您期望在未来完成以保持产品竞争力的任务的集合。 它是产品所有者和利益相关者(客户、团队、分析师)之间协作的结果。 它将定期更新,添加或删除新项目。

一般来说,它会比 sprint backlog 大。 它还将包括具有不同粒度级别的元素,在用户故事级别以下分解的项目更少。 产品负责人负责它。

sprint backlog是团队致力于完成的工作集合,无论是现在还是在 sprint 后期(通常为 1-4 周)。 它由团队承诺在即将到来的冲刺期间完成的用户故事组成。

但是,它也可能包括错误、重构工作等。 它通常更详细并分为活动,用户故事的技术实施处于最前沿。 这是 Scrum Master 和团队的责任。

Product Backlog vs. Sprint Backlog

是时候建立你的积压工作了

适当的计划和组织对您的成功至关重要。 这就是积压工作派上用场的地方。 如果生成和维护得当,积压工作将成为帮助团队应对不断变化、实现最高生产力并为业务和客户提供最大价值的工具。

在上面的博客中,我们描述了产品积压是什么以及它如何通过为利益相关者和团队建立一个共同点来帮助团队工作,以便实现最有意义的用户故事,允许灵活地响应不断变化的需求,以及在开发同一产品的多个团队之间建立一个共同点,以提高产品发布预测的准确性。