产品待办列表管理

什么是产品待办列表（Product Backlog）管理？

产品待办列表（Product Backlog）管理是对产品待办列表中的待办项进行调整和排序，以让Scrum团队能交付最可能有价值的产品。产品负责人负责管理产品待办列表。他们可以根据需要以适合的频率进行这项工作，也可以将这一责任委托给他人。然而，最终决定哪些工作现在做、以后做或不做的权力仍旧在产品负责人手上。

有效的产品待办列表管理的重要性

产品待办列表管理是一项重要的技能，它帮助 Scrum 团队更有效地工作在他们的产品上并交付价值。当产品待办列表被良好管理时，Scrum 团队可以按照有助于实现产品共同目标和方向的顺序处理最重要的条目。

相反，如果产品待办列表管理不善，产品负责人可能会与团队成员和利益相关者产生错位。这种错位通常会导致团队成员浪费时间在细化和处理客户并不需要的产品待办项上。此外，Scrum 团队会积累大量的产品待办项，这使得有效的产品待办列表管理几乎不可能。当产品待办列表变成一个长长的、杂乱无章的想法和任务列表时，它通常被称为“膨胀的产品待办列表”。这种类型的产品待办列表对于产品负责人来说难以有效排序，对于开发人员来说难以从中工作，也使利益相关者难以轻松理解客户将获得的潜在价值。

为了有效管理产品待办列表，产品负责人应确保待办列表适当排序并保持最新，以便：

• 增加透明度，以及对改进产品需要完成的工作的共识
• 与利益相关者就产品待办列表中包含和不包含的内容设定明确的期望
• 使 Scrum 团队的开发工作集中在交付下一个最有价值的条目上
• 使团队在共同的产品目标上保持一致，这是实现产品愿景的一步
• 减少在被认为重要性较低的条目上浪费的时间

产品待办列表管理使产品负责人能够与开发人员和利益相关者合作，明确团队为交付价值所追求的工作的“为什么”和“是什么”。然而，当团队花费大量时间深入讨论工作的具体执行方式时，这很快就会变得低效。这是因为更多的信息会在 Sprint 过程中浮现，工作可能会随之演变。Scrum 团队将学会对他们来说多少产品待办列表管理是足够的，以及他们需要多少信息才能开始工作，并在一个 Sprint 内完成。

产品待办列表管理活动

人们很容易陷入这样的误区：如果你想教别人什么，只需要简单地站在他们面前，给他们讲一讲这个话题就行。尤其是在专业环境中，这种方式既不高效也不受欢迎。那么，如何才能成为一名更好的老师呢？Scrum.org建议，你至少需要熟悉人们是如何学习的，如何有效地传达信息，以及如何评估学习者的目标是否已达成。

产品待办列表管理涉及对产品待办列表进行创建、精化和排序。

以下活动是产品待办列表管理和精化中涉及的不同类型的工作：

• 制定产品目标
• 决定包含和不包含的内容
• 对产品待办列表进行排序
• 随着更多信息的发现，向 PBI（产品待办项）添加更多信息
• 分解产品待办项
• 估算产品待办项的规模

制定产品目标（Product Goal）

产品目标（Product Goal）是帮助 Scrum 团队朝着产品愿景学习和进步的中间目标。

在制定产品目标时，它应当：

• 与产品愿景保持一致，并朝着产品愿景取得进展
• 清晰且简洁
• 以结果为导向，反映客户的需求或愿望
• 可衡量
• 在 Scrum 团队和利益相关者之间具有透明度和共同理解

产品目标示例：

以一家经营精品狗旅馆的公司为例。

精品狗旅馆的产品愿景：

成为狗寄宿的首选目的地，为我们的客人提供超越主人期望的奢华和宠爱体验。

以下是朝着这一愿景迈进的一些产品目标示例：

• 在明年夏天之前开设第一个分店，能够同时安全接待多达12位犬类客人。
• 在开设第一个分店后的6个月内，增加回头犬客的数量达25%。
• 创建一个安全可靠的环境，让狗狗可以无忧无虑地放松和玩耍。

产品目标是 Scrum 团队用来朝着产品愿景前进的假设。随着团队对利益相关者和客户需求的进一步了解，这些目标可能会发生变化，并帮助产品负责人管理产品待办列表。

决定产品待办列表包含和不包含的内容

一个有效的产品负责人确保那些能够改进产品和客户体验的有价值条目被包含在产品待办列表中。这意味着他们必须决定哪些内容应该或不应该包含在产品待办列表中。为了做好这一点，他们会花时间与客户和利益相关者交流，从中学习并收集反馈。

Sprint 评审是 Scrum 事件，在此期间，利益相关者和客户向 Scrum 团队提供反馈和见解，以便团队可以检查和调整产品待办列表。他们通过添加新的产品待办项以及移除那些看起来不够有价值的条目来实现这一点。

为了保持产品待办列表的精简，并确保开发工作集中在最重要的条目上，产品负责人有时需要说“不”。尊重他人并传达清晰的信息，对于帮助利益相关者和客户理解为什么某些条目应该或不应该包含在产品待办列表中起着重要作用。为了做到这一点，产品负责人应该：

• 明确沟通当前的产品目标：解释他们希望通过产品实现什么，以及产品待办列表中的工作应如何与这一目标保持一致。
• 具有同理心和好奇心：他们应该倾听并理解为什么某个需求会很重要。
• 与利益相关者重新审视“旧”的产品待办列表条目：这些条目已经在产品待办列表中存在一段时间了，但还没有重要到上升到顶部。检查它们是否仍然相关。
• 在决策过程中保持清晰和透明：用数据支持决策，如使用数据、客户满意度、当前价值、未实现价值等。
• 了解他们的产品、客户和产品愿景：深入了解产品、客户需求以及产品的长期愿景，以便更好地做出决策。

对产品待办列表进行排序

产品待办列表包含不同类型的工作，从新功能开发到缺陷管理。产品负责人对这些类型条目进行排序时，应该考虑它们为客户带来的价值。并不是每个功能都需要构建，也不是每个缺陷都需要修复，如果它们对客户来说并不重要的话。产品负责人以他们认为能够最大化产品价值的任何方式来排序产品待办列表。在排序产品待办列表时，他们会考虑多种因素，如业务价值、风险、投资回报率（ROI）、依赖关系和影响。

分解产品待办项

当产品待办列表中的条目庞大且复杂时，Scrum 团队通常会感到这些条目模糊不清且难以处理。将产品待办列表条目分解或拆分成更小、可管理的价值片段，可以让 Scrum 团队对需要完成的工作有更清晰的共同理解。这样做还能够更好地使 Scrum 团队在每个 Sprint 中至少交付一个完成的增量，并拥有更快的反馈循环。这使得 Scrum 团队可以优先考虑最重要的工作，并提高他们快速调整方向的能力。

举个例子，电子商务业务中有一个较大的产品待办项，即提供在线支付功能。这个功能包括让客户使用三种不同类型的信用卡、网上银行转账和礼品卡进行支付的能力。当团队分解这个产品待办项时，产品负责人能更好地决定首先追求什么最重要，并可以根据最佳判断来排序。例如，由于大多数客户使用信用卡支付，产品应该首先提供信用卡支付的功能。这种追求较小工作片段的方法允许更快速地学习，并确保产品中最有价值的功能能够更早地被开发出来。

估算产品待办项的规模

由于开发人员是实际执行工作的人，他们负责对工作的规模进行估算。团队可以使用多种技术来估算产品待办项的规模，例如：

绝对估算法：通常是基于时间的；例如，“这个 PBI（产品待办项）将需要 9 个小时的工作”。

相对估算法：使用一个让开发人员能够相互比较 PBIs 规模的尺度；例如，故事点或 T 恤尺码（小、中、大等）。

适当规模：识别出能够在单个 Sprint 内完成的小到足够处理的条目；例如，开发人员讨论是否可以根据他们的“完成定义”在单个 Sprint 内舒适地完成一个 PBI，如果不能，他们应该分解该 PBI。

开发人员应选择对他们团队来说最合理的估算方法。

产品待办列表管理的建议

为了使产品待办列表管理有效，可以考虑以下建议：

• 经常审查、重新排序和精化产品待办列表：

产品待办列表是动态的；它会随着反馈、实验学习成果以及市场条件的变化而演变。经常审查和重新排序有助于团队专注于接下来要追求的重要条目。

• 保持产品待办列表易于管理：

当产品待办列表变得过大时，Scrum 团队和利益相关者就很难分辨出哪些是重要的。此外，它会成为一个无用的沟通工具，并且管理和细化也会变得浪费。为了创建一个更易管理的产品待办列表，产品负责人应该以尊重但明确的方式决定哪些内容不应该出现在列表中。

• 可视化产品待办列表：

可视化产品待办列表有助于 Scrum 团队及其利益相关者看到接下来的工作，使他们能够提前思考。这通常会触发相关的讨论，并对需要改进产品的部分形成共同理解。

Scrum 团队应该选择一个所有成员（包括利益相关者）都能轻松访问的地方来可视化他们的产品待办列表，无论是物理墙还是虚拟工具。团队应根据具体情况选择适合他们的工具，但最终目标是优化透明度。

• 采取协作的方法：

尽管产品负责人负责管理产品待办列表，但他们不需要独自完成这项工作。实际上，与 Scrum 团队其他成员、利益相关者和客户合作，可以帮助产品负责人在管理产品待办列表时做出更好、更明智的决策。

• 不要直接跳到解决方案：

产品负责人始终关注客户的需求以及需要解决的挑战。这种关注产生了增强客户产品体验的想法。然而，产品负责人应该避免急于提出解决方案并将这些想法直接添加到产品待办列表中。

产品负责人应该与团队合作，将问题交给团队中的开发人员解决。这是一种利用不同经验、专长和视角的好方法。这使得开发人员能够想出创新和创造性的解决方案，并帮助他们培养对产品的所有权。