预IPM和Product细化之间有什么区别？

Question

迭代计划会议(IPM)等同于Sprint计划。在IPM之前，我们的团队举行一次IPM会议，帮助我们避免长时间的IPM，并获得更多关于故事的细节。这项技术是由我们的一位敏捷顾问提出的，但我在互联网上找不到很多关于IPM前的信息。

预IPM和Product细化之间有什么区别？在我看来很像。

Answer 1

我在两种情况下都见过“迭代计划”这个术语。第一个是在缩放的敏捷框架(如对安全迭代规划的描述)的上下文中，另一个是在对Scrum的一些描述中(比如这个页面/ CA技术页面或这个VersionOne页面)。我还没有找到“IPM前”事件、活动或会议的实例。

基于对获得更多故事细节的描述，这听起来非常类似于所谓的待办事项细化，有时甚至是积压整理。Rally页面提到“待办事项处理”，而Scrum指南的当前版本和SAFe则提到“待办事项处理细化”。

Scrum指南将精化描述为不仅仅是获取细节。在给出估计值和讨论Product的顺序时也是如此。通常，讨论Product项之间的依赖关系以帮助排序。Scrum没有为待办事项的细化提出具体的事件，只是说精化的方法是由Scrum团队决定的，不应该超过开发团队能力的10%。

当SAFe在小组积压上下文中讨论时，它也不会涉及太多关于待办事项处理的细节。它确实建议每一次迭代或每周至少进行一次精化会话，但它不限于单个会议时间框。这意味着每次迭代至少举行一次细化会议(或者更频繁地进行更长时间的迭代)，但细化工作可能在此会议之外发生。

我把这个活动称为“预IPM”会议时，我担心的一个问题是，您可能会关注下一个迭代计划或Sprint计划会话。对几个短跑项目进行精益求精是可以的，我建议你应该拥有这个。如果您在一个Sprint中超出了计划，并且提前实现了Sprint目标，那么拥有一个带有精良故事的有序产品待办事项簿可以让团队与Product一起为即将到来的工作提供一个快速启动的机会。它还让团队预览即将到来的工作，这可能会为设计决策提供依据。只是不要细化太多--随着产品在Sprints中的发展，您不会想最终使任何关于这项工作的讨论或评估无效。

Answer 2

我曾经参加过和运行过IPM前的会议，我将他们描述为为一个富有成效的IPM做准备。前IPMs不涉及估计或排序。IPM前的主要活动是澄清故事(例如修正模棱两可，增加接受标准)和选择在IPM中讨论的故事。预IPM是由一个小得多的集团进行的，通常只是PM和锚/技术的领头羊。澄清和选择活动是与一个小组，以避免浪费整个团队的时间，并导致更有成效的讨论。

产品积压精化的概念将前IPM的澄清和选择活动与IPM的估计和排序活动结合在一起。

以下是讨论和描述IPM前的一些链接和文章：

• 运行预IPM
• 负责管理最少可能召开的会议的方法
• 程序管理的过程
• 迭代预规划