在Sprint期间，开发团队在PBI上工作以构建增量（理想情况下，“增量”应逐步建立，一次建立一个或几个PBI）。Scrum指南指出这一点

在Sprint结束时，新的增量必须是“完成”，这意味着它必须处于可用状态.... 无论产品负责人是否决定实际发布，它都必须处于可用状态。

和

当Product Backlog项目或Increment被描述为“Done”时，每个人都必须了解“完成”的含义。它用于评估产品增量的工作完成时间。这是Scrum团队对Product Backlog项目的“完成”定义，每个都成员必须对工作的完整性有共同的理解，以确保透明度。

不完整 (incomplete) 或未完成 (unfinished) 的工作

想象一下，开发团队将5个PBI纳入Sprint。随着Sprint的发展，团队面临一些障碍，他们也发现并学习了一些他们以前不知道的事情。在Sprint结束时，尽管Scrum Master（消除障碍）和开发人员做出了最大的努力。团队，团队只能完成4个PBI，根据“完成定义”使“增量”为“完成”，对于第5个PBI，一些工作完成（比如编程），还有一些要完成工作尚未完成（比方说，测试）。该PBI是“不完整的工作”或“未完成的工作”。这是无意的（或不可避免的!!），然而这是一种浪费，团队应该努力在将来减少这种浪费。因为，如果一个故事的一部分没有完成，那么整个故事就没有完成! “ Undone意味着undone - 产品待办事项项目是”完成“或”未完成“，没有中间。

是什么原因导致冲刺中的用户情景未完成

作为 scrum master, 您一定会遇到这样的情况: 您到达冲刺结束, 并且仍有一个或多个用户情景未完成。团队未能完成他们预计在冲刺计划会话期间完成的用户情景。团队速度图将受到影响, 从而影响未来的规划。撤消的用户情景可能有多种原因,

• 一个队员在冲刺的一半时间里生病了。
• 一个用户故事被发现比最初想象的要大得多。
• 过于乐观的开发人员。即使在小冲刺中, 一些开发者也会过度投入。最好用一对一的会议来解决。
• 迷你瀑布。团队在冲刺中启动所有用户故事, 要么在冲刺后期完成, 要么根本不完成。最好的解决方法是鼓励团队尽一切可能完成单一的故事。
• 糟糕的估计-团队认为这个故事是一个配置更改, 但它实际上是硬编码在17个地方, 需要大量的更新和广泛的用户验收测试之前部署。最好的方法是让团队在产品积压优化会话中走到一起, 并借助他们在之前的冲刺中了解到的内容, 重新检查为现有用户故事提供的估计。

不完整的用户故事意味着浪费

不完整的PBI不是增量的一部分，而是返回到产品Backlog。** 这不会自动转到积压的顶部并级联到下一个Sprint**， 而是产品负责人负责订购它（基于与开发团队的讨论，PBI的价值，市场因素等）。

这种模式保持简单, 并防止团队玩数字。这样做的目的是将 "完整" 的故事 (不要调整项目的大小以只代表剩余的未完成工作) 放回产品积压工作, 以便重新确定优先级。不要在当前冲刺的速度计算中包括在未完成的用户情景上花费的任何精力。速度是完成率的反映, 而不是团队付出的努力。当然, 在当前的冲刺中, 球队不会得到任何速度积分, 因为它 ' 没有完成 ', 但它也不会搞砸速度, 因为速度将是球队在冲刺过程中实际交付的东西的真实反映。平均而言, 在一些冲刺中, 速度数字在任何情况下都会平均出来。

相關Scrum & Agile 英語文章

• 什么是Scrum工件？
• 完成与接受标准的定义
• Scrum中Ready的定义是什么？
• 如何写短距离目标？
• 什么是Scrum中的产品Backlog？谁负责呢？
• 如何优化产品积压？
• 什么是Scrum中的Sprint Backlog？