产品积压

帮助你的Scrum团队成功的14个首要原则

与流行的看法相反，产品负责人对于产品积木的组成和顺序并没有独裁的权力。相反，Scrum作为一个框架是基于一个微妙的制衡系统、协作和联合决策，以减少风险；例如，产品负责人爱上了他们的解决方案而不是客户的问题。了解更多关于产品积压的关键原则，从产品积压的大小和增长到产品积压是否有必要放在首位。(一些精益从业者对其存在的合理性有争议）。

根据Scrum指南的产品积压

首先，让我们看一下Scrum指南的当前版本，以便更好地理解产品积压的原则。

产品积压（Product Backlog）是一个新兴的、有序的列表，包含了改进产品所需的内容。它是Scrum团队开展工作的唯一来源。

[产品所有者]的决定在产品Backlog的内容和排序中是可见的，并通过Sprint Review中的可检查的Increment可见。

Scrum团队可以在一个Sprint内完成的产品Backlog项目被认为是可以在Sprint计划活动中选择的。他们通常在精炼活动后获得这种程度的透明度。产品积压细化是将产品积压项目分解并进一步定义为更小更精确的项目的行为。这是一个不断增加细节的活动，如描述、顺序和大小。属性往往随着工作领域的不同而变化。

将要进行工作的开发人员负责确定大小。产品负责人可以通过帮助他们理解和选择权衡来影响开发人员。

产品目标是在产品积压中。产品积压的其他部分是用来定义 "什么 "来实现产品目标的。

源于此Scrum指南2020。

关于《Scrum指南》中产品Backlog引文的完整概述，请参见《Scrum指南》重排版2020。

Scrum作为一个战术框架，善于将经过验证的假设有效地送到客户手中，以关闭学习循环，允许检查最初的假设和决定过程，以建立一个Increment，并随后调整下一个Sprint的准备工作。

但归根结底，在一个复杂的环境中，第一个挑战是弄清楚什么是值得建立的。因此，一个成功的Scrum团队需要放弃这样的想法，即产品负责人奇迹般地确定如何进行才符合客户、组织和团队的最佳利益。相反，要把每个人都融入到建立一个系统中，成功地把经过验证的、可能有价值的假设输入到产品积压中。(了解更多：产品积压的完善：14个首要原则）。

换句话说，仅仅存在产品Backlog并不能保证成功，因为Scrum同样适合于有效地建立没有客户需要的东西。

产品积压原则

这是我为成功的Scrum团队制定的14条产品Backlog原则:

产品目标驱动结果产品积压反映了Scrum团队的产品目标。它不仅仅是一个所有需求的存储库或核算系统，也不是扔给团队的。随着计划在复杂环境中的变化，对团队产品目标的解释也在变化，因此，产品积压项目的组成和顺序也在变化。根据定义，产品积压是动态的。
产品负责人的特权产品负责人的职责是代表客户和组织，在给定的约束条件下，将开发人员的工作价值最大化。他们通过管理基于内容和顺序的产品积压来做到这一点。然而，与流行的看法相反，这并不意味着他们也有独裁的权力。Scrum是一个微妙的制衡系统；因此，其他团队成员应该对产品负责人的每一个提议提出质疑：产品负责人，难道没有什么更有价值的东西我们可以处理吗？
这是一个系统的一部分产品Backlog是一个重要的，但不是系统的唯一部分，它组织了Scrum团队中创造价值的工作流。融入产品积压的产品发现部分也应该得到同样的关注。
减轻风险产品积压的目的是减轻风险。就其本身而言，产品积压没有什么其他价值。
#NoPolitics把产品Backlog作为恼人的利益相关者的安抚器是很诱人的。然而，只有透明度和尊重才能解决这个问题。如果Scrum团队不考虑在某个需求上工作，就告诉他们。相反，把那些徒劳的需求添加到产品积压中，让它们腐烂，只会推迟这个对话。然后，当它最终发生时，请放心，情绪会给这次谈话带来负担。
增长如果你的产品后记的增长速度超过了Scrum团队交付产品后记项目的速度，那么你很可能正朝着成为一个功能工厂的方向发展。
规模很重要任何超过Scrum团队在2-4个Sprints内所能处理的工作的产品Backlog都是浪费的。产品Backlogs是不能扩展的。(一些有精益意识的人甚至会认为，仅仅是产品积压的存在就已经反映了浪费。)
每增加一个项目都是昂贵的增加一个产品Backlog项目可能只需要很少的努力。看起来，扩大产品积压是免费的，因此是避免 "错过 "重要东西的一个很好的策略。然而，问题是积累所谓的 "免费 "项目，因为处理越来越大的产品积压的成本会成倍增加。
储存想法产品积压似乎是一个很有吸引力的地方，可以把想法、思路和草图都压倒。它们总得有个地方去，不是吗？当然，只是不要为此目的滥用产品积压，因为它代表了一个更高的构建确定性的地方。确保你只将Scrum团队之前验证过的项目添加到产品Backlog中。
垃圾桶是你的朋友删除那些Scrum团队超过8周没有处理的产品积压项目。大多数情况下，这些都是噪音。相反，如果它们是一个信号，它们会回来的。
没有保证产品积压反映了Scrum团队在某个特定时刻对时间的最佳利用。它是一个复杂、动态情况的快照。因此，如果一个需求进入了产品积压，这并不意味着团队会建立它。也许，有更有价值的东西可以选择。
运送产品BacklogScrum团队不会在Sprint计划的时候根据其顺序来运送产品Backlog。相反，Scrum团队会集体确定Sprint目标，然后通知Sprint Backlog的内容。在大多数情况下，产品积压可以为Sprint Backlog贡献项目。然而，这并不是自动的。如果有必要，开发人员会当场创建所有对完成Sprint目标至关重要的工作项目。如果这是规则而不是例外，请问你为什么要花时间创建产品Backlog。就不要再这样做了。
发货可以建立信任没有什么比交付有价值的增量更适合与利益相关者建立信任。所以，请使用产品日志来支持Scrum团队的工作。
遵循计划我们不会因为创建全面的产品Backlog而得到报酬；例如，在为未来12个月做前期计划的时候。忙着在Jira上添加产品Backlog项目并不能创造价值，而是危险的噪音；想想损失厌恶症。当你的产品积压已经达到了史诗般的规模，从而上升到资产级别时，仅仅是 "遵循计划 "会更容易被接受。尽管如此，它也不过是一个工具。

结论

产品Backlog可以成为Scrum团队成功之路上的一个重要工具。然而，在一个复杂的环境中，如果没有专家知道所有问题的答案，仅仅把所有的需求塞进Jira项目中是不行的。比清单本身更重要的是创建一个围绕着把经过验证的假设输入产品后备库的过程。为此，请考虑上述的产品Backlog原则，以帮助你成功应对这一创造性的挑战。