产品待办列表

产品待办列表简介

产品待办列表（Product Backlog）的目的是代表Scrum团队已知的，为交付产品所需要完成的所有工作。团队可以使用产品待办列表来决定他们接下来应该做什么。
产品待办列表包括：

产品待办项（PBIs） – 每一项代表需要完成的工作。
产品目标（Product Goal） – 描述Scrum团队当前对产品的长期目标。

产品待办列表是查找Scrum团队当前对所有必须完成的工作的知识的单一且透明的方式。它们被维护为一个有序列表。

单一性：每个产品应只有一个产品待办列表。这意味着不应为不同类型的PBI设立单独的待办列表，例如没有单独的缺陷报告待办列表或用户体验（UX）工作的待办列表。所有内容都应放在同一个产品待办列表中。此外，如果多个Scrum团队在同一个产品上工作，他们应使用同一个待办列表。
透明性：产品待办列表应易于访问，并用于驱动Scrum团队和利益相关者对PBIs的共同理解。
当前性：产品待办列表是“涌现的”，意味着它会随着时间的增长、缩减和演变。它不是一个静态的工件，而是根据开发过程中发现的信息以及来自利益相关者、客户和市场的信息频繁更新。
有序性：PBIs的顺序由产品负责人决定。顺序可能基于多种因素，如商业价值、风险、投资回报率或依赖关系。

产品待办项（PBIs）

每个PBI代表团队打算完成的工作。关于每个PBI应包含哪些信息、如何编写或格式化、每个PBI的粒度或用于维护产品待办列表的工具，没有固定规则。
PBIs以最适合团队的形式编写。例如，它们可以写成用户故事、假设、缺陷报告或任何其他有助于团队的格式。它们通常包含标题、描述、规模估算和价值估算。
PBIs可以描述新功能；现有功能的改进；当前产品中存在的必须解决的问题；产品的非功能性需求（如可靠性标准）；新想法；实验等。只要有助于团队理解需要做什么，PBIs可以是任何内容。
PBIs在开发者需要的详细程度上编写。初次创建时，它们可能非常高层次，仅作为占位符。随着时间推移，随着更多信息被揭示或变得更为重要，它们会被改进和完善。最终，它们将包含足够的信息供开发者采取行动。
产品负责人负责创建PBIs。他们可以委派此责任，因此团队中的任何人都可以向待办列表添加PBIs。
规模估算是由开发者完成的，因为只有他们才能估算每个PBI涉及的工作量。有许多方法可以估算PBIs的规模：

绝对估算：通常是基于时间的；例如，“这个PBI将需要9小时的工作”。
相对估算：使用一个尺度，让开发者可以相对比较PBIs的大小；例如，故事点或T恤尺码法。
流量指标：基于团队的历史数据，如吞吐量。
适当规模：识别可以在一个Sprint内完成的小项目，通常使用基于流动的方法；例如，开发者讨论是否可以根据他们的“完成定义”在一个Sprint内舒适地完成一个PBI，否则应将PBI分解。

产品目标

产品目标（Product Goal）描述产品的未来状态。它是对产品待办列表的“承诺”，意味着它旨在为Scrum团队提供焦点，并作为一个可以衡量进展的目标。
产品目标没有特定的格式或指示其规划周期有多长。Scrum明确规定一次只有一个产品目标，并且在开始下一个目标之前，要么实现它，要么放弃它。
为了更全面地理解这一点，我们需要考虑Scrum和产品目标所处的更广泛的背景。组织通常根据其业务战略选择创建或维护产品。这一战略往往导致创建一个非常高层次的产品愿景。这通常是关于产品可能成为什么以及它可以解决的客户问题的一种理想愿景。这种愿景可以非常激励团队，但有时Scrum团队成员可能难以理解他们如何为此愿景做出贡献。
为此，产品目标是一个具体、可操作且可衡量的目标。它充当产品愿景与Sprint目标之间的桥梁。它是朝着愿景迈出的一步，定义得足够明确，使团队可以利用它来计划并评估他们朝着该愿景取得的进展。
产品目标为产品待办列表提供了上下文。Scrum团队创建将实现产品目标的产品待办项，并使用Sprint和Sprint目标逐步接近实现该目标。一旦达成目标，团队会制定一个新的产品目标，以进一步实现产品愿景。
有时，新的信息浮出水面，导致团队放弃或重新制定他们的产品目标。这不是失败，而是增量和实验性开发的自然结果。

产品待办列表精化

产品待办项（PBI）随着时间的推移不断演变。它们最初是模糊的想法，并随着更多信息的揭示而逐步改进。最终，它们会被定义得足够清晰，以便可以被纳入Sprint待办列表。
将PBIs不断改进直至其准备好进行工作的活动被称为“精化”（Refinement）。大多数Scrum团队在工作会话中进行精化，在这些会话中，他们对产品待办列表中的项目进行集中讨论。在这些会议期间，他们会创建对每个项目的具体目标的共同理解，并讨论待办列表中项目的顺序。
产品待办列表的精化在一个Sprint期间可能发生多次。在某些Sprint中，待办列表顶部的PBIs可能已经足够细化，甚至不需要进一步精化。因此，产品待办列表的精化并不是Scrum中规定的一个事件。
然而，为了创造更大的清晰度和共同理解，定期让产品负责人、开发者和相关利益相关者参与精化讨论是一种好的做法。自管理团队决定精化应多久进行一次，以及每次会议应由谁参加。