冲刺项目需要更长的时间，然后才能完成。我们应该做什么？

如果Scrum中的项目花费的时间比预期的长，我们该怎么办？我之所以这么问，是因为我一直在注意开发人员正在努力完成的项目，因为它比最初想的要困难得多。

在这种情况下，我们应该

• 将项目从sprint移回产品目录，以便我们可以满足sprint的时间表？
• 移至较容易的冲刺项目，并将有问题的冲刺留到时间表结束
• 在sprint审查中证明为什么在当前sprint中无法向利益相关者完成该项目？

将来如何避免这种情况？是由于缺乏预先计划，还是我们没有努力将冲刺项目分解为较小的项目？

我想用“项目”来表示“任务”。

对软件进行计划乐观与软件本身一样古老。Scrum的好处是您将很快面对它并创建它的可见性：这就是为什么团队速度是基于过去的数据而不是将来的估计的原因。

要完成故事，您还必须完成比预期困难得多的任务。没有任何理由推迟他们。（这就是为什么“完成的定义”如此重要的原因）。如果那意味着团队没有一个故事，那就太糟糕了，您将在下一次回顾中谈论一些事情。速度会下降（变得更加现实），团队将学会做出更好的估计，或者为不可预见的任务留出更多的安全余量。产品负责人将对他的发布计划有更现实的看法。

如果Scrum中的项目花费的时间比预期的长，我们该怎么办？

假设按项目讲故事，则通常在sprint结束时将其放回产品待办事项列表中（并可能在下一次迭代中进行计划）。团队在当前迭代中为此获得零分。

如果故事足够大，另一种选择是将其垂直切开。例如，故事“产品目录搜索”可以分为“按类别搜索”和“全文搜索”，但不能分为“搜索形式”和“搜索结果”。

将来如何避免这种情况？

没有简单直接的答案。在Scrum中，您确实会在每次迭代中冲刺回顾，通常您会在团队中讨论这些事情。有许多不同的可能性：

• 团队或某些团队成员度过了糟糕的一周
• 您的团队水平地整理工作项（例如，后端->前端->质量检查）
• 故事误会太大了
• 团队通过添加并非完成故事完全必要的额外工作来“镀金”故事。
• 故事本质上很大，您需要更长的冲刺（不太可能）
• 团队估算的故事不准确（不连贯）
• 该项目有很多技术债务/烂代码库，而且速度太慢
• 您没有正确（或根本没有）测量和估计您的冲刺容量。

等等等

您说您不会完成它，但这还不错，这只是数据。

“满足冲刺时间轴”不是目标。您的目标是完成用户案例。时间轴只是一个工具，可以帮助您衡量和了解冲刺中可以完成的工作量。

如果您确定无法完成sprint中的工作，则一种解决方案是将其移至优先级列表的底部，然后首先处理sprint中的其他事件。然后，剩下的时间就可以开始处理了。重新估计进入下一个冲刺的工作，然后完成。

确保在回顾中讨论发生了什么问题，以便将来可以改进估计。

如果任务花费的时间比预期的长，则应在回顾中提出并进行讨论。早期分析中是否遗漏了一些内容？这是团队尚未经常做的事情吗？有很多可能的原因导致某些事情可能花费比最初估计更长的时间。

团队应该尝试使任务尽可能地完成，然后在回顾性讨论未来的策略。如果团队刚开始使用Scrum，那么这可能是计算团队初始速度的一部分。有些团队可能认为他们可以做到20分，而有些团队则可以做到60分，这就是每次冲刺相同数量的点可以连续执行的程度。

将来会发生这种情况，因为只要团队有未完成的新任务，就会花一些时间来进行估算。这是学习过程的一部分，应该不足为奇。

当任务开始花费比预期更长的时间时，我们通常在公司中所做的就是将其划分为较小的任务。

这样，我们就不会将开发速度太慢归咎于开发人员，但我们也承认该任务的设计不正确。

另一件事可能是将该任务分配给您的开发团队的另一位成员，以避免您已故的开发人员陷入困境。如果任务真的很关键，则可以使用某些XP作为解决方案。