在2002年的时候，加拿大一家能源公司正在引入Scrum，那个时候他们亲身体验了缺乏透明性所导致的后果。他们在其中一个部门建立了一个Scrum试点，这个部门的经理大卫非常喜欢Scrum提供的透明性。他希望开发人员用Scrum进行开发，这样他不但可以掌握项目进度，还可以在部分功能完成的时候试用。
但不幸的是，大卫并没有确保增量都是完成并可用的，他甚至不知道他要那样做。 在第三个Sprint结束的时候，开发人员告诉大卫他们已经完成了整个项目的30%，他们利用SQL向大卫演示了成果。大卫对此非常高兴，他希望开发人员能够教他的员工使用SQL，并希望这些完成的功能能够马上投入使用。然而，令大卫没有想到的是，开发团队告诉他这些功能还不能投入使用。开发团队告诉大卫，那些增量只能用于演示，在正式上线之前还有大量的工作要做，例如要修复数据不稳定，数据库有时会丢失信息，甚至是整个数据库损坏的问题。于是，大卫向开发团队询问完成前三个增量还需要多长时间，而开发人员的回答是还需要额外的两个Sprint。于是大卫要求团队继续工作直到前三个增量真正完成。最后，他们花了额外的两个Sprint才将之前拖欠的工作补全。大卫为自己大肆宣扬Scrum而感到难堪，让他更难堪的是他一直向上级报告的进度并不是真实完成的进度。
产生这种问题的原因就在于大卫没有能够理解真正“完成”的意义，因此接受了一些只有部分完成的增量。
在这个故事里可以看出，真正的“完成”和透明性对于是多么重要。如果你曾经像大卫一样接受了不完整的增量，那么这些增量将来就会回过头来找你麻烦。在没有完成的工作上面添加新的工作，会使没有完成的工作更加难以修复。未完成的工作同样也阻碍了透明性，使你无法知道距离目标还有多远，也无法知道项目的实际成本是多少，最终导致无法有效地管理你的投资。
因此，当一个增量被认定为完成时，应该没有任何剩余的工作。
