你会拆分产品待办项（PBI）吗？

产品待办项（Product Backlog Item，简称PBI）多小才合适？

尽可能小，但仍然有价值。

产品的核心在于提供价值。这既是为用户和客户提供价值，也是为企业提供价值。

• 设计用户体验（UX）
• 创建用户界面（UI）
• 分析和添加功能和非功能细节
• 编写代码和进行同行评审
• 构建数据库
• 验证期望的功能是否按预期工作

• 部署功能到生产环境等

很多团队有时会将这些任务分解为价值单元，并开始将这些任务当作产品待办事项。但请停止这样做。是的，这些活动很重要，但它们本身不能为用户、客户或企业提供价值。

产品待办事项（PBI）应当是具有实际价值的项目，即它们应该是可供客户使用的有形内容，同时旨在协助产品开发团队获取真实反馈。

我们来探讨一下如何在不降低价值的前提下创建小型的PBI。

一种常见的拆分方法是根据不同的用户角色。不同的用户群体可能有不同的需求或问题，因此在拆分PBI时应考虑这一点。

例如，我们正在构建一些与电子商务相关的产品和一个产品功能，我们关注的是“购物车”。让我们将这个功能称为“查看购物车”。

对于购物车，顾客在结账之前会检查金额和数量。然而，“查看购物车”的功能也可以被客户服务团队使用，他们在结账过程中帮助顾客解决问题。

• 作为在线顾客，我想查看我的购物车，以便在结账之前检查数量和金额。

• 作为客户服务执行人员，我想查看购物车，以便在结账过程中帮助遇到问题的顾客。

• 是否可能存在不同种类的客户或用户？
• 如果是的话，是否有比其他更多的需求/问题？
• 他们与我们的产品/系统互动的方式是否不同？

• …

例如，我参与了一个构建学习管理系统（LMS）的项目，在这个项目中，我们设计了一个能让学习者进行评估以验证他们的学习的功能。

• 创建评估的培训师/内容创建者
• 验证他们的知识/学习的学习者
• 想要收到通知的学习者的直线经理

• 工作流程中的典型步骤可能是：
• 学习者登录到LMS门户
• 搜索可用的评估
• 注册可用的评估
• 进行评估
• 学习者获得结果

• 创建（C）：添加新记录
• 读取（R）：检索现有记录而不修改它
• 更新（U）：修改现有记录

• 删除（D）：删除现有记录

例如，如果我们正在构建一个人力资源（HR）系统，业务操作规则和政策可以帮助我们将PBI进一步拆分。以下是可能导致更多价值单元的问题示例。

• 创建新员工记录：谁可以执行此操作，如何执行此操作，是否存在多种创建记录的方式，是否可以进行批量创建。

• 读取员工记录：谁可以阅读员工记录，直线经理可以看到哪些细节，HR管理员可以看到哪些细节。

• 更新现有员工记录：哪些角色可以更新员工记录，直线经理可以更新哪些记录，HR管理员可以更新哪些记录。

• 删除现有员工记录：谁可以执行删除操作，删除记录时会发生什么。

以上每个问题都可以成为一个独立的PBI，对某些问题的回答可能会创建更多的PBI。更小但同样有价值。

我看到过许多PBI的验收标准非常庞大，涵盖了一个PBI中的多个场景和用例。这些庞大的PBI包含进一步拆分为独立价值单元的机会。

例如，我们正在为系统添加登录功能。这项任务可以根据用户角色和场景进行拆分。一个场景可能是快乐路径，即在正确的用户名和密码组合之后成功登录。但还有多个快乐路径和非快乐路径的场景。

• 用户名正确但密码不正确
• 用户名不正确但密码正确
• 忘记密码
• 多次尝试使用不正确的凭据
• 记住我的登录信息
• 通过我的Google账户登录
• 通过我的社交媒体账户登录

• 通过单点登录进行登录

并非所有这些在早期开发阶段都是必需的。有些可能永远不需要。但这些都是较小的PBI，可以帮助产品负责人更好地设置工作的优先级。更小但同样有价值。

许多企业和产品遵循各种业务规则，这些规则可以单独实施。有时，并非所有这些业务规则都需要同时执行。

举例来说，用户在我们网站上购买课程。在结账时，作为英国的增值税（VAT）注册企业，只有当客户来自英国时，我才需要收取增值税。

这可以分为两个PBI：

非增值税客户的故事：

• 当我调和公司的月度支出并更新财务记录时
• 我希望收到清晰指示无需支付增值税的发票，

• 以便我能够高效管理会计流程，确保财务报告准确，并避免有关税务责任的混淆。

增值税客户的故事：

• 当我审查公司采购并准备报税时，
• 我希望收到详细列明增值税费用的发票，

• 以便我能够准确计算和报告增值税费用，确保遵守税收法规，并促进简化的财务审计。

更小却同样有价值。

原文地址：