敏捷开发：Product Backlog细化的艺术

我在Scrum培训课程中听到的一个常见问题是，“我们应该做多少Product Backlog，在Product Backlog中应该包含多少细节?”

首先，让我们看一下Scrum指南。

Product Backlog细化

根据Scrum指南，Product Backlog细化是为其中的项目添加细节、估算和子条目等行为。但是Scrum并没有规定你如何去做，这是有原因的。

改进是一个持续的过程。它从不停止，因为需求和机会从未停止变化。预先详细说明所有内容会造成浪费，也会延迟价值的交付。

不同的产品和不同的团队将在频率、技术和细节级别上有独特的需求。

即使是在同一产品上工作的Scrum团队，也需要随着时间的推移改进产品Backlog，以适应新的情况。Scrum团队需要找出适合他们的方法。那么他们是怎么做到的呢?

自组织和经验主义。

应用Goldilocks原理（也称金发姑娘效应，英文为Goldilocks principle，是指凡事都必须有度，而不能超越极限。）来帮助团队进行实验，通过检查和适应找出最适合他们的方法。

Goldilocks原理和Product Backlog细化

我们的目标是平衡从活动中获得足够的利益，同时尽量减少潜在的浪费。

让我们首先看看产品Backlog的6个好处：

增加透明度

澄清价值

把东西分解成可消费的东西

减少依赖

预测

融入学习

现在让我们深入研究每一个问题，看看如何应用Goldilocks原理。

# 1 -增加透明度

产品待办事项列表是一个有助于提供透明性的工件。它是产品计划的“唯一真理来源”。添加细节可以增加您计划交付的内容的透明度，以及您的进度。

金发女孩的问题

利益相关者和Scrum团队如何理解产品的计划?

利益相关者对所交付产品的惊讶程度有多频繁?

# 2 -澄清价值

当您阐明关于价值的细节时，您试图通过产品Backlog条目(PBI)实现的结果就会更加清晰。你为什么要这个?用户的利益是什么?商业利益是什么?

这有助于开发团队构建正确的东西来满足需求。这可能会影响所请求的内容、估计以及产品所有者和开发团队确定实际需要的顺序。这段对话产生了一种共同的理解。

金发女孩的问题

在Sprint期间，您经常发现，对业务需求或您所建的东西没有共同的理解?

您在Sprint回顾中或发布后发现PBI不满足用户或业务需求的频率是多少?

#3 -Product Backlog Item(条目）拆分的足够小。

您希望PBIs足够小，以便开发团队可以在Sprint中完成多个项目。在一个Sprint中有多个PBI可以给团队一些灵活性来实现一个Sprint目标并交付一个“完成”增量。

金发女孩的问题

你有多少次没有交付“完成”的增量?你有多少次没有实现sprint目标?

这是什么原因导致发现sprint中期PBIs比你想象的要大得多，还是拆分粒度不够细?

# 4 -减少依赖关系

依赖关系常常会变成障碍，使团队陷入停顿。虽然您可能无法避免所有这些问题，但是您应该尽可能地减少它们。这对于Scrum团队之外的依赖关系尤其重要。您可以以不同的方式分割和拆分pbi。您可以重新排序，或者您可以与其他团队协作帮助提前解决依赖关系。有许多选项，并且至少希望依赖项是透明的。

金发女孩的问题

在一个危及Sprint目标的Sprint中，您发现依赖的频率有多高?

在Sprint中，PBIs被依赖项“阻塞”多久?

什么时候需要重新安排产品待办事项列表来考虑依赖关系?这对产品所有者优化价值的能力有多大的影响?

# 5 -预测

经过改进的产品待办事项列表与Scrum团队交付工作产品能力的历史信息相结合，可以帮助您进行预测。有些产品需要预测未来的几个sprint，以帮助与涉众沟通发布预期。其他产品将不需要做预测超过目前的冲刺。大多数产品都属于这一范畴。

与预测相关，为了获得资金，您可能还需要一个经过改进的产品待办事项列表。Scrum并不禁止预先计划。Scrum简单地说要考虑你的努力，潜在的浪费，以及不管你做多少分析，你都不能完美地预测一个复杂领域的未来。

金发女孩的问题

用户、客户和其他涉众实现新特性或功能需要多少时间?如果他们的交货期更短，会有什么影响?

用户、客户和其他涉众在发布预测中需要多少细节?如果细节较少，会有什么影响?

# 6 -融入学习

根据经验，在开发产品的过程中学习相关的知识，因为当你发现环境发生变化时，你会更好地理解如何实现产品愿景。

金发女孩的问题

您如何调整产品待办事项列表以反映新了解产品的演进功能，以及用户是如何响应这些变化的?

错过了什么机会?是什么阻止你更早的做出反应?

把一切都融合在一起

您已经与Scrum团队讨论了关于细化好处的Goldilocks问题。(Sprint回顾是定期进行这些对话的好机会。)现在是时候让Scrum团队决定如何调整他们的过程来改进Product Backlog列表了。这些都是开放式问题，而不是简单的是或否问题，这是有原因的。

你在寻找平衡，或者“刚刚好”的地方。你希望在尽量减少浪费的同时，获得足够的提纯好处。

通过探索1-6所获得的信息，Scrum团队现在可以在考虑收益和浪费之间的平衡。

金发女孩的问题：

你多久做一次Product Backlog细化?你想花多少时间详细描述Product Backlog?

你想让谁参与到Product Backlog细化中来?需要什么知识和观点?你将如何实现共享理解?

在Sprint之前，您希望“准备”多少Product Backlog条目?“准备”对你来说意味着什么?

你想如何传达关于PBIs的重要细节?哪些方法运行良好，哪些方法不工作?

你如何确保你能看到全部，而不陷入细节?