压缩积压细化

关于积压改进(我们美国人过去称之为梳理)的文章很多，而且很多都是好的。关于这种做法有很多可说的。然而，我还没有看到任何关于你是否应该对你最初的积压做不同的处理。因此，我将在这篇文章和下一篇文章中回答这些问题:

• 如何细化和评估最初的待办事项安排?
• 您如何优化和估计额外的工作的额外故事或后续积压？
• 那些方法不会是一样的吗？

通常，当我旋转一个新的敏捷团队时，他们没有初始积压。尽管如此，父母组织恰好始终知道他们希望团队能够进行愿景或使命或宪章 - 尽管它可能无法清楚地沟通。有时，经常被称为PRD，MRD或BRD的记录要求。无论如何，如果没有积压的用户故事，我通常会举办一个故事写作研讨会以获得球滚动。现在我们有一个原油积压，需要精制。

这篇文章不是关于想法从哪里来，甚至不是关于如何将已经存在的东西转化为用户故事。这里的重点是如何进行那是初步细化会议，然后有什么不同呢在后续的细化会话中。

对于最初的细化，我推荐压缩细化。在此之后，我建议继续改进。

压缩积压细化

当炼制最初的积压时，通常在旋转一个新的敏捷团队之后，通常有人在指挥中有人想知道，“为什么没有任何人编码？”已经开始有很大的压力即可开始。除非他们仍在努力包装之前的项目，否则球队可能急于开始。与此同时，我们想知道我们期望通过这项新工作完成，当我们可以到达下一个版本或者在发布日期滚动时，我们有多少积压。对于我的客户来说，告诉他们他们会得到他们在得到它时会得到的东西是不够的。我的客户需要可预测性。我们还需要细化待办事项列表，以识别依赖项、风险和有较长交付时间的项目。无论如何，它需要一些时间来创建，完善和估计积压，表达团队，做Sprint-0的东西并获得滚动。我们希望精炼积压的好工作，但我们不能永远努力完成。

因此，我们采用压缩的方法来细化待办事项列表。

故事已经写好了，我们有一大堆粗糙的故事，我们需要快速地完善它们。在压缩细化方法中，我们将举行一系列细化会议。可以是半天到全天的会议，大部分时间都是这样。整个团队都参加。请带午餐，最好是丰盛的午餐。在会议期间，您可能会发现自己在敏捷管理工具中实时更新故事。这通常是低效的，所以要找到正确的平衡点。有些编辑可能会让整个团队都参与进来，争论措辞和意义。其他的编辑可以由旁边房间里的其他人来完成。当然，其他编辑将离线进行。

这种压缩的方法往往非常详细和缓慢，因为我们在会议期间从粗糙的故事到完善的故事。既然我们已经如此深入地讨论了它们，我们不妨用规划扑克当我们去。

因为我们的故事讨论在使用这种方法时是非常详细的，所以您可以在前2或3个sprint中召开一个简短的sprint计划会议。

标点改进

在项目模式而不是产品模式下运行的组织往往会为每个项目的项目进行这种压缩的细化方法。当当前项目仍然正在进行时，他们花费一点时间让积压器准备好下一个项目。

这是在大批处理中完成的积压细化。这是带有大潮汐的滚动波规划。这通常不是最好的方法。在这一压缩细化之后，让我们继续持续改进。

不要谈论渐进或精化

我不是在说逐步阐述甚至细化。敏捷意义上的精化更多的是将史诗分解为功能，功能分解为用户故事，然后提供故事的细节(接受标准)及其可视化规范。向精化添加“渐进”一词意味着我们或多或少地在一段时间内按时完成。

下面是我们如何同时进行渐进精化和压缩精化:我们可能仍然渐进精化史诗和特性，然后有一个紧张的待办事项精化周期，开始一个项目，但仍然对用户故事、他们的接受标准和视觉规格随着时间的推移。我写的是什么是我们在压缩的时间内完善和估计大多数故事，说，一周，也许是两个或我们是否会随着时间的推移而改进。

推荐

这有一些缺点。压缩的细化不允许做一些研究可能需要的长时间时间，图一些事情出来，了解一些新技术，把必要的建筑跑道到位，用3个派对锻炼合同，或者得到其他群体构建依赖的作品。此外，我们有时需要额外的时间来浸泡。我们需要退后一步并再次看大局。由于这些事情，我们可能最终有一个精致的积压不良或糟糕的计划。

出于这些原因，我建议将开关从项目思维和标点改进到产品思考和持续改进。这是我下一篇文章的主题。