并非产品待办列表中的所有项目都会同时具有相同的大小和详细程度(即功能/史诗/用户故事和任务)。我们计划很快开展的 PBI 应该接近待办事项的顶部,体积小且非常详细,以便可以在近期的 sprint 中开展工作。我们在一段时间内不会处理的 PBI 应该位于待办事项的底部,尺寸更大,细节更少。
用例/功能 是您的最终用户将拥有的他们以前没有的功能。例如,通过手机在线购买商品将是一项功能。您的产品路线图通常包含功能级别的要求。
史诗 是将功能分解为可操作需求的下一个阶段。它们是与功能相关的一系列操作。使用信用卡通过手机从购物车中购买商品的能力将是史诗般的。它比功能(在线购买商品)要小,但它比单独支持购买商品的单个信用卡集成要大。我们不允许将比史诗更大的需求纳入发布计划。
用户故事 是最小的需求形式,仍然可以独立存在。用户故事由一项价值行动或一项价值整合组成。例如,使用 Visa 卡通过手机从购物车中购买商品就是一个用户故事。使用万事达卡购买商品可能是不同的集成,因此可能是不同的用户故事。用户故事足够小,可以添加到 sprint 中并开始开发。我将在接下来的部分中详细介绍用户故事。
任务 是实现用户故事所需的内部步骤。在 sprint 计划期间,用户故事被分解为任务。虽然需求是最终用户所做的事情,但任务是开发团队为使需求工作所做的事情。
产品待办事项 (PBI) 的粒度级别
该图描述了不同层次的需求分解,以适应开发路线图的一系列冲刺
- 上图的顶部是橙色的、最大的砖块。它们代表系统要实现的业务目标,即用例或用户功能。
- 下一个级别是大于单个 sprint 但小于发布的 PBI。让我们将此级别的 PBI 称为史诗。
- 在第三级,我们发现 PBI 的大小适合 sprint ——它们可以在几天而不是几周内完成。这些项目符合团队的 就绪定义, 可以表示为用户故事。
- 在最低级别,这些 PBI 可以选择性地从用户故事分解为任务,并在单次迭代结束时交付。
产品积压
产品待办列表列出了所有需要的可交付成果。其内容按业务价值排序。如上所述,最重要的项目显示在产品待办列表的顶部,因此团队知道首先要交付什么。待办事项项目的优先级可能会发生变化,可以添加和删除需求——因此,产品待办事项是一个持续维护的计划,以实现不断增长的业务价值。
产品待办事项
产品待办事项 (PBI) 是构成产品待办事项的元素。产品待办列表项的范围可以从规范和要求,到用例、史诗、用户故事,甚至是错误,或 有时间限制的 研究任务。
冲刺计划流程
通常需要准备 Sprint 计划,以确保产品 Backlog 已被细化到适当的详细程度,并带有估计和验收标准 (这是产品 Backlog 细化的目的)。如果在产品Backlog细化过程中对Product Backlog Items进行了分析和思考,那么在Sprint Planning会议中最优先的Product Backlog项目可以很好地理解和容易选择。
概括
Product Backlog Refinement 过程的目标是让 Product Backlog 项目处于准备好的状态以进行 sprint 计划,因此产品 backlog 项目是:
- 团队中的每个人都足够清晰易懂
- 小到足以包含在 sprint 中