根据事后诸葛亮表示，小朋友最怕父母问的一个问题就是“作业写完没？”短短五个字，对幼小的心灵而言，却具有如同原子弹般的杀伤力。因为这个问题的答案，决定了接下来的时间，小朋友们能不能：

出去玩

看海绵宝宝

打网络游戏

吃点心

看漫画

眼看人生中这么多美好的事情，就要被一个简短的是非题给毁掉了，幼小的心灵学会了什么叫做善意的谎言：“写……完……了……呀！”（通常回答的会很心虚，事实是完全一个字都没有动，或者乱写一通）

父母自然也不是省油的灯：“写完了啊，拿出来我看一下。”于是当场就被抓了现行。随着时间飞逝，小朋友长大了，从此过着幸福快乐的日子……错！这个“功课写完没？”的问题变成了：

代码写完了没？

Bug除光了没？

产品可以上线了没？

为了不伤老板的心，你大声说出：“写完了！除光了！随时可以上线了！”

但是此时的你，心中却浮现出小小的呐喊：

写完了，还没有测试……

这个Bug解决了，但是以另外一个Bug的身份继续存在着……

随时可以上线，附赠Bug无数只以及糟糕的用户体验……

随着年纪渐长，功课有没有写完这个问题越来越难回答，因为常常连做功课的人也不知道，功课的范围有多少，合适才写得完。

在Scrum里面，Scrum团队如何知道需求是否已经做完、可否被Product Owner验收？所以，Scrum提到团队需要有一个对于“完成的定义”（The definition of done:DoD）。这个定义可能包含：

产品可以运行，通过单元测试，通过其他各种测试（整合测试、功能测试、系统测试、安全性测试、效能测试等等）、产品已经经过重构，更新重要设计文档，可以运行等等。

唯有实现定义好“Done”，才能知道每一个Sprint真正完成了多少功能，而不是灌水的数据，也才有可能在每个Sprint结束时，产生一份“可以交给老师的作业”（potentially shippable product）。至于何时定义DoD，在Sprint planning meeting是一个不错的时间点。每个Sprint依据产品所需以及团队技术能力来决定每个Sprint的DoD内容。随着产品的进行以及团队技术能力的提升，DoD的要求也会随之增加。例如，产品刚才是的前几个Sprint团队的DoD内容可能只包含完成每一个Story的功能需求，之后慢慢加上要求开发人员必须为自己所写的程序加上单元测试。再慢慢的加上考虑非功能面的需求是否有达到，像是产品的设计是否容许扩容，用户界面UI是否容易操作等等。

总之，随着团队的技术能力以及对于产品的开发流程的熟悉度越来越高，DoD的涵盖范围也越来越广，每个Sprint结束时所交付的软件也越来越完整。DoD的最高境界就是做到每个Sprint所完成的产品达到立即交付或上线给用户使用的程度。