如何避免产品 Backlog 的这七个常见错误

产品 Backlog 是一个简单而强大的工具，用来捕获产品创意和调整产品决策，并且为开发工作的方向提供指引。不幸的是，想要用好产品 Backlog 这个工具并不容易。本文讨论了七个常见的产品 Backlog 错误，以帮助您识别和规避这些错误。

产品 Backlog 太大

几年前，一家医疗保健公司期望我能够在敏捷转型上提供一些帮助，特别是敏捷转型后对产品管理的影响。这个公司的敏捷转型团队所关心的一个关键挑战是如何选择正确的产品 Backlog 工具。一开始，这让我觉得很诧异。但是，当我知道他们的 Backlog 的条目有超过 4 万条时，我知道这才是问题所在。 毋庸置疑，这是我迄今为止见到的最大产品 Backlog。但我发现，我经常会遇到几百到几千个条目的 Backlog。但这样的产品 Backlog 是难以理解的，更不用说调整优先级和更新了。这是有问题的，特别是对于新产品和那些需要进行重大调整的产品，比如延长产品的生命周期，这些情况下，产品 Backlog 往往是不稳定的，需要频繁的调整，有时候调整会很大。

因此，当产品面临不论是市场、业务还是技术相关的不确定性和变化时，您都应该努力保持产品 Backlog 尽可能简洁。以下三种技术将帮助您解决以下问题：第一，按照主题对较小的条目分组。第二，保持低优先级条目为较大的颗粒度。第三，也是最重要的一点，产品 Backlog 要关注具体的产品目标，拒绝并删除那些和目标无关的条目。

产品 Backlog 太详细

还有一次，我去帮助英国一家大型慈善机构的团队，他们的任务是为他们筹款活动创建一个新网站。产品负责人告诉我，她已经尽可能完善了产品 Backlog，但开发团队仍然不满意。看着 Backlog，我注意到它只包含详细的用户故事，没有史诗或其他粗粒度的条目。 但是，过于详细的产品 Backlog 会让你只见树木不见森林：信息实在太多了。这反过来又使得很难对条目进行优先级排序和更新。更重要的是，它很可能包含猜测的和错误的需求条目，尤其是在充满不确定和变化的情况下。

因此，我建议您尽量刻意地从粗略和不完整的初始产品 Backlog 开始，尤其是在您的产品还在很早期或经历较大变化时。然后，根据从用户、客户和利益干系人那里获得的反馈，来演进您的产品 backlog。这样，您就可以最大限度地减少管理产品 Backlog 的投入，并且基于经验性的证据来做产品决策，而不是直觉。

产品 Backlog 细化程度不够

前一段时间，我跟一个英国的公司合作，他们是一家连接消费者和手艺人，比如花匠，水管工的初创公司，产品负责人期望我能够帮忙他们解决 Sprint Planning 的一些问题：开发团队经常过度承诺，从来都不能完成 Sprint 中的所有工作。

当我在他们的办公区观察的时候，我发现墙上有一些颗粒度很大，很粗略的卡片，我问产品负责人，这些卡片是产品 backlog 的一部分内容吗？他回答我说：”不，这就是产品 Backlog“。

因为产品 backlog 的条目没有住够细化，并且没有达到准备好的状态，团队做不好 Sprint 计划就不足为奇了。虽然您不想使产品 Backlog 过度的详尽，但您应该确保那些最高优先级的条目已准备就绪。准备就绪须满足以下三个标准：

第一，足够清晰明确，开发团队完全理解。第二，基于完成的定义，它们可以在一个迭代内完成。第三，它们是可测试的。

最好让开发团队的成员（或部分成员）一起让这些高优先级的条目处于准备好的状态。

产品 Backlog 只是愿望清单

一些产品 Backlog，如上面提到的 40，000 个项目，类似于一个愿望清单，一个大而全的目录本，其中有些东西，你可能永远都不需要它。这种 Backlog 的麻烦不仅在于它通常太大。它还会导致”Feature Soup 特性汤”，包括了一堆松散切不相关的功能堆积的产品。这导致了弱化的价值主张和糟糕的用户体验，这似乎不是一个伟大产品的象征。 但是，如果这些 Backlog 是如此糟糕，为什么它们会存在？

主要有两个原因：第一，缺乏战略一致性和重点：第二，缺乏赋权。前者意味着没有产品目标，以指导决策需求条目是否应添加到产品 Backlog 中。例如，您可以集思广益，并决定添加所有这些故事。谁知道呢，他们可能会在某个时候派上用场！ 缺乏赋权会导致您（产品负责人）难以拒绝利益相关者的要求，并感到有义务满足这些请求。但是，如果您不能说不，您的产品 Backlog 就会有为个人利益相关者及其个人目标服务的危险，而不是让产品为用户和企业创造的价值最大化。 为了防止您的产品 Backlog 成为愿望清单，请参考一些如下两个小贴士：

第一，定义产品目标，并将您的产品与产品路线图等战略计划保持一致（如下所述）。第二，有勇气说不。拒绝任何与产品目标不一致的想法和要求。

产品 Backlog 没有做好优先级排序

前段时间，我跟一家新医疗保健产品的产品经理合作，当时我建议他对产品特性的优先级进行排序。他惊讶地看着我，回答说：”我不能。它们都是高度优先级的。当然，排列优先级需要决策哪些条目是重要的。如果一切都是高度优先级的，一切都同样重要。这实际上意味着没有什么是优先级。但是，如果没有明确的优先级，开发团队缺乏方向。

如果您难以对产品 Backlog 进行排序，请尝试以下两个方法：第一，确保产品 Backlog 条目达到了前面提到的具体的产品目标。第二，确定少量的几个优先级排列的因素，我喜欢推荐的三个因素是风险、成本效益和依赖性。

以下是应用它们的方式：首先，按风险对产品 Backlog 进行优先级排序，考虑用户、技术和业务的相关风险。与开发团队一起评估所有 Backlog 条目，并将那些风险最高的条目移到产品 Backlog 的顶部。这种方法可以加速学习，而且当变更的成本更高时，它可以让你尽快失败，避免以后更大的损失。一旦您解决了关键风险，按成本效益对产品 Backlog 进行排序，并将这些条目移到顶部，从而获得最大的收益。最后，使用前面的两个因素时，请不要忘记考虑依赖性。包括对个别团队成员和其他团队的依赖，因为这些依赖会影响 Backlog 的优先级。

产品 Backlog 不共享

几年前，我跟荷兰的一群产品负责人合作，他们想让开发团队能够更好地交付他们需要的产品。情况是这样的，这些产品负责人对产品 Backlog 进行了梳理细化，并且自己编写了用户故事，然后将高优先级需求条目交给了在罗马尼亚的开发团队进行开发。团队竭尽全力去正确地理解用户故事，但大多数情况，他们都会出错，因为他们对最终用户的需求知之甚少。

对一个局外人来说，出现上述情况的原因通常是缺乏沟通，但是，我发现开发团队没有正确参与产品 backlog 的工作的情形非常普遍。改进、优先和更新 Backlog 工作应该是团队合作，如下图所示。作为产品负责人，请开发团队成员与您合作处理 Backlog 工作，期待他们给您提供支持。如果情况不是这样，那么请在下一次 Sprint 回顾中讨论这个问题。

协作共创产品 Backlog 可以带来如下两个好处：第一，发挥开发团队的集体智慧和创造力，让产品 Backlog 条目更优，而且这些条目可以根据团队需要确定详细程度。同时，在共创过程中，产品负责人可以将用户和需求的知识全面地传递给开发团队。 其次，它使团队成员感到受到重视和尊重。它赋予个人权力，并增加他们开发产品的动机，他们不再是被要求工作。他们现在为产品决策做出贡献，并帮助构建解决方案。 如果您不是在定期的和团队成员（至少部分成员）一起共创产品 backlog，您可以尝试一下。建立一个共创研讨会，无论是现场还是在线，并请您的 Scrum Master 提供环境和支持。最初，这可能需要您花更多的时间处理产品 Backlog 问题。但从长远来看，它应该会减少你的工作量。这甚至可能促进开发团队愿意自己完成一些改进工作。

产品 Backlog 缺乏战略一致性

产品 Backlog 缺乏战略一致性是一个非常普遍的错误，上述的几个错误的根本原因也是如此。产品 Backlog 没有和战略规划（比如路线图）建立连接。产品 Backlog 如果没有战略指引和明确的产品目标，就会导致 backlog 变大，变得难以价值排序，最终成为一个愿望清单。

我在前文中提到的巨大的那个产品 backlog 也是如此：产品的战略目标不清晰，导致很难确定哪些项目应添加到 Backlog 中。 因此，我强烈建议您将产品 Backlog 与可执行的产品路线图联系起来，该路线图以产品目标的形式说明产品在未来 9 到 12 个月内应创造的价值，如下图所示。例如：产品的目标可能是获取用户、提升活跃度、偿还技术债务，降低成本等。

在上图中，是一个目标导向、基于成果的产品路线图在指引产品 Backlog。这是通过将下一步的产品目标从路线图复制到 Backlog 中来完成的。然后，目标有助于确定应包含在产品 Backlog 中的需求条目，即只有那些帮助实现该目标的需求条目。