在Scrum中细化产品待办事项列表时，不要犯这个计划错误

的细化Scrum的流程决定了产品待办事项列表中项目的细节、顺序和大小。目的是确保我们有最高顺序的产品待办事项项(pbi)准备Sprint。在细化过程中，团队进行讨论什么我们将在每个产品待办事项列表项中交付。尽管这很容易让人理清头绪如何我们将在讨论期间交付每个PBI，在这个阶段计划是错误的。

在细化过程中，我们想要确定工作项是为谁工作的，以及我们试图完成什么。我们可能会讨论如何消除每个PBI的依赖关系，或者如何将每个项目削减得更小，以便在Sprint中交付。为每个PBI创建完整的交付计划(如何)发生在Sprint计划中，而不是细化过程中。

让我们来解释一下原因。

想象一下，我们的Scrum团队正在进行的产品是一个房屋装修。我们的PBIs包括粉刷客厅、餐厅和卧室，并更换客厅和餐厅的厨房台面和地板。

alt文本:一个剪贴板上的项目清单包括:油漆客厅，油漆餐厅，油漆卧室，更换厨房柜台，更换客厅的地板，更换餐厅的地板。

现在想象一下，我们的团队在产品待办事项列表细化过程中花费了大量的时间进行决策如何我们将交付每一项。粉刷客厅时，我们决定由苏购买油漆、画笔和其他油漆用品。乔治将为起居室买油漆和刷子。在Sprint Planning，团队决定停止粉刷客厅而且餐厅进入冲刺。我们应该让两个人去油漆店吗?我们的交付过程不再有意义了。我们的Scrum团队现在需要重新规划交付这些pbi的方法。

计划如何在细化中是浪费的。如果我们花时间详细描述完成每个PBI的计划，而产品负责人后来改变了产品待办事项列表中项目的顺序，这可能会影响我们的交付计划。此外，当我们的Scrum团队以细化的方式计划交付方法时，我们冒着将产品负责人锁定在一个特定的产品待办事项列表中的风险，或者由于不得不在Sprint计划事件中重新计划而造成浪费。

在没有规划方法的情况下，我们如何确定pbi的大小?

您可能想知道，在不讨论如何交付PBI的情况下，我们如何确定PBI的大小。这就是平衡之举发挥作用的地方。

我们的Scrum团队可能需要一个关于如何交付项目的高级概念，以帮助我们确定项目的大小。但是我们应该尽量减少对方法的讨论，一旦我们有足够的信息来估计PBI的大小就停止讨论。保存Sprint Planning事件的细节。

回到我们的房屋装修的例子，我们可能会讨论，我们将需要考虑购买物资所需的时间作为规模的一部分，但我们不需要分配任务或进一步分解它们。

正是在Sprint计划期间，我们的团队将选择他们将交付的产品待办事项列表项，决定如何完成它们，并制定一个Sprint目标。我们有时将“如何”的细节称为“任务分配”，因为Scrum团队经常在此事件中将每个选定的PBI的任务计划添加到Sprint Backlog中。

结论

交付产品待办事项列表项目的方法可能会根据我们的Scrum团队将哪些项目拉入Sprint而改变。因此，在Sprint计划事件而不是在细化过程中讨论每个PBI的交付方法是最有意义的。在细化过程中，Scrum团队可能不得不在高层讨论交付计划，以帮助确定规模。但是，我们应该注意在这个阶段限制计划，以避免一旦我们知道我们将把什么项目拉到Sprint中，重新计划的潜在浪费。

要了解更多关于如何充分利用Scrum事件的信息，请注册Rebel Scrum专业Scrum Master课程。对于那些刚接触Scrum框架的人，请注册Rebel Scrum应用专业Scrum课程来了解Scrum的事件、工件和职责。

有兴趣从你的同龄人那里学习，同时享受乐趣?参加我们富有洞察力的讨论和激动人心的演讲Scrum日，麦迪逊，计划于2023年9月14日在美国威斯康星州麦迪逊举行。