产品积压的完善

产品积压的完善是一个持续的过程，以创建可操作的产品积压，使Scrum团队能够在瞬间运行Sprint Plannings。因此，细化是为了在所有团队成员之间建立关于 "为什么"、"做什么"、"怎么做 "的一致性，甚至可能是关于Scrum团队的产品目标即将开展的工作的 "谁"。因此，产品积压的完善是一个关键的成功因素，因为它极大地提高了团队定期交付有价值的增量的能力。

下面的14条原则概括地描述了成功的精炼方法的基础。

根据Scrum指南，产品Backlog改进的目的

Scrum指南在几个与产品积压管理和Sprint计划相关的场合提到了完善工作。

"在Sprint期间，产品Backlog会根据需要进行完善"。

"[Sprint Planning: What can be Done this Sprint?]Scrum Team可以在这个过程中细化这些项目，这可以增加理解和信心。"

"[产品积压项目]通常在完善活动后获得这种程度的透明度。产品积压细化是将产品积压项目分解并进一步定义为更小更精确的项目的行为。"

"[产品积压细化]是一种持续的活动，以增加细节，如描述、顺序和大小。属性往往随着工作领域的不同而变化。"

产品积压完善是一个持续的过程，以创建可操作的产品积压，使Scrum团队能够在一瞬间运行Sprint Plannings。

Scrum团队通过在小组中或与整个Scrum团队一起定期完善产品Backlog项目来达到这种熟练程度，而不仅仅是在每个Sprint中作为Sprint计划的一部分进行一次。完善背后的想法是与所有团队成员建立一个共同的理解，即为什么一个特定的工作项目是有价值的，开发人员应该建立什么，以及如何在技术上实现该工作。

Scrum团队的这种能力对于通过定期交付有价值的Increments来建立对管理层和利益相关者的信任至关重要。

虽然2020年的Scrum指南放弃了之前关于时间分配的指导，但它仍然是一条实用的规则，即Scrum团队应该保留10%的时间用于产品积压的完善。

一般来说，围绕以下问题构建完善过程是有益的：

哪些项目不再相关了？
我们需要拆分哪些项目？
哪些项目我们可以用新的信息来更新？
这种更新是否改变了以前的估计？
特定项目的优先级是否有变化？
我们是否有任何新的议题或学习还没有被考虑？(如果有，我们需要把这些作为新的产品积压项目来捕捉）。

在我眼里，卡尔-波普尔（Karl Popper）的下面这句话完美地描述了产品Backlog的完善是每个Scrum团队的关键成功因素的原因。

"永远记住，你不可能以这样的方式说话而不被误解：总会有一些人误解你"。

产品后记细化的14条成功原则

这是我的14条产品积压细化的首要原则：

精炼的目的：精炼的最终阶段是对 "为什么"、"做什么"、"怎么做 "以及 "谁来做 "的共同理解，同时开发人员有信心在一个Sprint内创建相关的产品Backlog项目。
时间：一个产品Backlog项目的完善可能需要几轮。保持短而频繁的细化。
持续完善：产品积压的完善是一个持续的活动，而不是在60分钟内匆匆完成一个检查表的孤立事件。团队成员花时间来完善他们感兴趣的产品积压项目，例如，当他们学到与任务相关的东西时。完善产品Backlog项目是Scrum团队在Sprint期间工作的一个常规部分。
不需要 "全体出动"：产品后记的完善并不意味着所有的团队成员都要一直参与所有的完善活动；对于那些对相应的产品后记项目感兴趣的人来说，它是可以选择的。
完善是为每个人服务的：产品负责人应努力让整个Scrum团队参与到产品Backlog的完善过程中，而不是仅仅依靠 "首席工程师 "和一个设计师。采取包容性方法的原因很明显。当试图解决一个复杂的问题时，没有专家，但有许多相互竞争的想法。因此，将完善活动的积极参与者限制在少数团队成员中，会增加确认偏差的风险，因为意见和专业知识的多样性被人为地限制了。
局外人：邀请利益相关者和主题专家参加完善会议，他们可以促进团队对问题和合适的解决方案的理解。
DoR："准备就绪的定义 "代表了初级Scrum团队的临时训练轮或反模式。
不要太过提前细化：保持产品积压聚焦于产品目标，大约涵盖三到六个Sprints的工作。这种关注将使细化工作保持最小，因为过多的细化是浪费。只细化那些可能被建立的产品积压项目。
用户研究：产品积压的完善和产品发现是密切相关的，并且是平行进行的。用户研究是细化活动的一部分，包括开发人员，例如，进行用户访谈或用生产数据建立原型。
INVEST：在完善产品积压项目时，要接受由Bill Wake推广的INVEST原则：I-独立，N-可协商，V-有价值，E-可估计，S-小，T-可测试。(资料来源：《中国经济周刊》)
Done和验收标准的定义：一个有意义的产品积压细化需要一个坚实的 "完成的定义"。此外，在细化过程中要理解 "完成的定义 "和 "验收标准 "之间的区别。此外，对如何应用这两者达成共同的理解。
质量：在完善产品积压项目时，要考虑技术债务和重构，因为这两者都是开发人员的持续努力，可以轻易地吸收他们15-30%的时间。
估算：一旦你把数字搞清楚了，用估算来结束完善工作是有意义的。在完善工作结束时估算产品积压项目有一个目的：了解我们作为一个团队是否对为什么、做什么和如何做都有共识。或者换句话说，估算是为了找到结尾来继续前进。估算过程中的差异，可能是指对产品积压项目性质的理解不同。或者，它们可能指向团队成员之间的技能差距，团队可能应该解决这个问题。无论如何，这些问题都会增加在即将到来的Sprints中无法交付价值的风险。当你的Scrum团队决定将估算作为完善过程的一部分时，无论如何都要坚持使用相对估算--故事点、T恤衫尺寸或赛狗，如果你喜欢的话--而避免使用绝对估算。这些都植根于工业时代和泰勒主义，与个人表现、效率、报酬和硬性承诺有关。此外，人类也不擅长这些。
不是所有的事情都是用户故事：不要成为用户故事格式迷信的受害者。"作为一个数据库管理员，我想把数据库软件升级到5.x版本，所以...."用户故事是从用户的角度来描述未来的系统状态的。所以，虽然每个用户故事都是一个产品积压项目，但不是所有的产品积压项目都是用户故事。还有其他的工作项目，如bug、尖峰、或上面提到的非功能需求。因此，在细化过程中，通过强制利用统一的产品Backlog项目格式，避免浪费大家的时间。此外，完善是关于团队成员之间发生的对话。它不是关于选择正确的文档格式。

总结

产品Backlog的完善是一个持续的过程，以创建可操作的产品Backlog。Scrum团队的这种能力对于建立与管理层和利益相关者的信任至关重要，因为它允许定期交付有价值的增量。完善是在复杂环境中降低风险的一个非常有效的方法。