Scrum：如何优化产品Backlog？

(英文原文: How to Refined Product Backlog?）

并非产品待办事项中的所有项目都具有相同的大小和详细程度（即 features / eprics /用户故事 (user stories 和任务 task）。我们计划很快开展工作的Product Backlog Items 应该接近积压 (Backlog) 的顶部，尺寸很小，而且非常详细，以便它们可以在短期冲刺 (Sprint) 中工作。我们将在一段时间内不工作的PBI应该在积压的底部，更大，更不详细。

用例 / 功能是最终用户以前没有的功能。例如，通过手机在线购买商品将是一项功能。您的产品路线图通常包含功能级要求。

Epics是将功能分解为可操作需求的下一个阶段。它们是与该功能相关的一系列操作。使用信用卡从购物车通过手机购买商品的能力将是史诗般的。它比一个功能小（在线购买商品），但它比单个信用卡集成更大，可以单独购买商品。我们不允许将大于史诗的要求纳入发布计划。

用户故事是可以独立存在的最小要求形式。用户故事由一个价值行为或一个价值整合组成。例如，使用Visa卡从购物车通过手机购买商品将是一个用户故事。使用万事达卡购买物品可能是一个不同的集成，因此是一个不同的用户故事。用户故事足够小，可以添加到sprint并开始开发。我将在后续章节中详细介绍用户故事。

任务是实现用户故事所需的内部步骤。在sprint计划期间，用户故事被分解为任务。虽然需求是最终用户所做的事情，但任务是开发团队为使需求工作所做的工作。

产品待办事项（PBI）的粒度级别

该图描绘了需求分解的不同层，以适应开发路线图的一系列冲刺

如何优化产品积压？

• 在上图的顶部是橙色，最大的砖块。它们代表了系统要实现的业务目标，即用例或用户功能。
• 在下一个级别，PBI比单个sprint更大但比发布更小。让我们在这个级别的史诗中调用PBI。
• 在第三级，我们发现PBI的大小适合冲刺 - 它们可以在几天而不是几周内完成。这些项目符合团队的Ready of Ready，可以表示为用户故事。
• 在最低级别，这些PBI可以选择从用户故事中分解为任务，并在单次迭代结束时传递。

产品积压

产品Backlog列出了所有必需的可交付成果。其内容按商业价值排序。如上所述，最重要的项目显示在产品待办事项的顶部，以便团队知道首先要交付什么。积压项目优先级可能会发生变化，需求可以添加和删除 - 因此产品积压工作是一项持续维护的计划，可以实现不断增长的业务价值。

产品待办事项

产品待办事项（PBI）是构成产品Backlog的元素。产品待办事项项目可以包括规格和要求，用例，史诗，用户故事，甚至错误或时间框研究任务。

产品Backlog项目细化

Sprint计划流程

Sprint Planning通常需要做好准备，以确保产品Backlog已经被细化到适当的详细程度，并具有估计和验收标准（这是Product Backlog Refinement的目的）。如果在产品待办事项优化过程中分析并仔细考虑了产品待办事项项目，则在Sprint计划会议中，可以很好地理解并轻松选择产品Backlog项目。

 

Product Backlog Refinement流程的目标是使产品Backlog项目处于准备状态以进行sprint计划，以便产品积压项目为：

• 团队中的每个人都清楚并且可以理解
• 足够小，可以包含在sprint中进行发展

其他推荐的Scrum文章

• 什么是Scrum工件？
• Scrum中Ready的定义是什么？
• 如何写短距离目标？
• 什么是Scrum中的产品Backlog？谁负责呢？
• 如何优化产品积压？