当团队没有在Sprint中完成工作时：查看和完成工作的3条提示
根据定义，Sprint是一个时间框。 您应该说：“放下铅笔！” 在冲刺结束时，展示您的工作并进行反思。
敏捷团队的主要问题之一是他们无法在sprint中完成工作。 每个团队都是独一无二的。 但是，我最经常看到这些原因：
- 团队成员执行多项任务 ，因此他们不会在sprint中完成工作。 当团队成员在太多故事中同时执行多个任务 （一次开始有太多故事）时，以及经理要求团队成员参与多个项目时，我已经看到了这一点。
- 人们在整个架构中都是专家，而不是整个架构中的团队。 此原因通常会创建WIP（进行中的工作）。 当人们跨架构工作时，他们经常创建“ UI故事”，“中间件故事”，“ DB故事”和“测试故事”。 这对于提高资源效率非常有用。 您可以向所有人展示人们已被充分利用。 （是的，这里有些讽刺。）但是，软件，尤其是采用敏捷方法的软件，是关于流程效率的 ，即人们作为一个团队一起完成一个故事。
- 故事太大了。 团队无法在冲刺中完成一个故事，也不要介意他们的估计。 故事过大有几种可能的原因。 当PO不在功能集中寻找第一个可能的值时，我已经看到了这一点。 当团队不知道代码或测试的状态并且问题过于复杂而无法在不到几个月的时间内完成时，我也看到了这一点。 我以前写过一些小故事 。 有时，故事太大了，因为代码没有单元测试来支持更改。 您认为您可以在这里改变这件小事，变得糟透了，它炸毁了一切。
如果您的团队没有在冲刺中完成工作，该怎么办？ 这是三个技巧：
- 团队合作 。 我一直在谈论配对，蜂拥而至和围攻 ，这是因为该团队致力于将一个故事作为一个团队向下传播 。 这解决了正在进行中的太多故事的问题。 而且，如果您的经理要求您从事其他工作，您可以说不。 那是因为您的团队依赖您与他们合作。
- 确保人员（尤其是领导者和经理）了解流量效率。 我喜欢跟踪累积流量，以便每个人都可以看到尚未完成的工作清单。 （请参见下图。）
- 评估此故事是一个小故事还是整个功能集。 您可能想要使用Jeff Patton的用户故事映射或Ellen Gottesdiener的发现来交付 。 请参阅我有关产品所有者和学习的系列，以获取有关如何考虑故事策划和讲习班的更多详细信息。
这是来自实际项目的累积流程图。 在此项目中，PO试图“超越”团队。 他成功了。 他“完成”了创作团队从未开发过的故事。 我称之为浪费。
团队在编写故事（分析）部分方面做得很好，但是对于开发人员进行中的工作却有些麻烦。
开发人员之所以拥有WIP，是因为有时他们的职能经理会将他们拉到其他项目中。 这个团队对蜂拥而至并没有那么兴奋，所以经理们感觉好像可以把人们拉走。
整个团队（PO和技术人员）必须一起学习故事。 他们花了大部分时间在这个项目上，以取得一天的故事。 他们的部分问题是故事“应该”很小。 但是，他们具有很少的单元测试的旧代码库。 团队花费大量时间来创建单元测试以支持其工作，以便他们知道更改是否正确。
这个团队不是完美的，他们也不必如此。 他们发现可视化他们的工作对于停止多任务和完成故事至关重要。 而且，一旦团队达到第11次迭代，他们的WIP就更少了。
以下是该团队尝试的操作：
- 通过团队跟踪故事的进度。 跟踪累积流量。
- 可视化任何团队成员所做的任何“其他”工作，而每个人都应按照这个故事进行工作。
- 选择您拥有的最小故事。 团队合作。 是的，一次只写一个故事。
您可能需要向经理解释您正在尝试，这样可以提高速度。 请记住， 速度就是能力 ，您正在学习速度，因此可以进行更好的估算。
如果您的团队无法在sprint中完成工作，请不要自动将工作转移到下一个sprint。 可视化工作位置，选择排名最高的工作，并以团队的形式一次完成一项工作。
仅在团队一次成功完成一个故事后，才增加您的WIP限制。 如果需要更多帮助，请阅读“ 创建成功的敏捷项目” 。 您的问题可能不在故事或团队合作中，而在项目系统中的其他地方。
当团队没有在冲刺中完成工作时，这就是项目系统的问题。 这表明系统必须更改。 使用所有定性和定量工具（包括回顾）来诊断和试验您的团队。