在20世纪90年代的中期，迭代和增量开发的团队设置周期性地让应用程序达到“零缺陷里程碑”，变得很流行。微软Visual C++小组的前总监Jim McCarthy经常写到或提到“零缺陷里程碑”。
零缺陷并不意味着产品没有缺陷或缺少的功能，而是指产品达到某个里程碑设置好的质量标准。产品经过测试达到这个结果。零缺陷里程碑的本质是并非由某个人单独设定该里程碑，而是所有人都参与安排该里程碑；没有人单独达到该里程碑后可以离开，而是所有人都必须达到才能离开。这使得团队能发现项目的哪个方面存在麻烦。在某个里程碑，同时也可以让团队和它的领导层有机会认识到整个项目的状态，对错误实践得出结论，对不好的设计决定做出补救，以及通过改组实现最佳的团队绩效等等。在每个里程碑，团队都能形成非常的关注和自省。
尽管McCarthy的零缺陷里程碑对很多团队仍然是一个好的目标，但是Scrum团队设置了更高的眼界，它瞄准在每个Sprint结束时，可以实现潜在可交付软件的提交。那么什么是“潜在可交付”呢？对“潜在可交付”的完全地定义需要业务领域和应用程序的知识，这些只有包括产品负责人和ScrumMaster在内的团队才会拥有。事实上，任何一个新团队需要做的一件事情是讨论并同意“完成了（done）”的定义，它定义了与所在环境相适应的某个潜在可交付的产品增量。Sprint里的每个产品backlog条目只有在满足了这个标准后，才可以认为完成了。第十三章“产品Backlog”介绍了作为单个用户故事的验收标准–满足条件的概念，在很多方面，组成团队“完成了”定义的内容与应用到所有产品backlog中的用户故事的满足条件是一样的。
举例来说，比如ePlan服务，它给小公司提供退休账户，定义的“完成了”包括“编码、测试、代码检入、格式良好、可集成和具备自动化的测试”。每个产品backlog条目被团队实现时，要遵循这个期望以及其他条目具体要求的满足条件。ePlan服务的用户故事是“作为一个用户，我可以用信用卡支持账户维护费用，从而该费用就不会从我的税后退休账户中扣除。”针对这个用户故事，我们假设产品负责人提供了如下的满足条件：
•接受Visa、MasterCard和American Express
•不要在系统中存储信用卡信息
•所有的交易使用加密的方式处理
因此，不仅这些满足条件必须符合，而且在项目具体的“完成了”的定义（编码、测试、代码检入、格式良好、可集成和具备自动化的测试）也需要符合。
识别＂潜在可交付＂的指导方针
尽管在企业或团队中建立适合它自己上下文环境的“已完成”的定义，取决于企业或团队自己，但是还是存在某些指导方针是适合大多数企业中的大部分Scrum项目。
潜在可交付意味着测试过
尽管确切地定义要潜在可交付哪些内容由组织或团队决定，但是如果将测试排除在该定义之外，我无法想到在哪种情况下可以适用。
在Sprint结束时，我们当然期望这些新的特性是没有缺陷的,并且没有将缺陷引入到原有的功能。对于某些产品，我们可能无法确保这点，但我们总是想尽量接近它；也就是说，某些特别目的的测试类型，比如集成测试、性能测试、可用性测试等等，可能不会在每个Sprint中都执行，而是将这些测试类型安排在某个发布Sprint中执行，该发布Sprint可以插入到每几个常规的Sprint之后。
举个对恰当地使用发布Sprint的例子，有一家我工作过的银行，它有一个基于大型机的大型旧应用系统。该系统包含了几百万行的COBOL代码；一些开发人员维护它，并且这些维护人员已经使用了20年的顺序式开发方法；现在这个系统已经没有新的功能开发。不过幸运的是，测试该系统只需要3周的手工测试工作量。
该银行还有一个相对较小的、有300,000行java代码的应用程序，其提供了对相同的财务数据基于网络的访问。两个应用程序共享一个数据库，这意味着该网络应用程序写入数据库中的数据有可能会影响到该大型机应用程序。该网络应用程序是由一个Scrum团队编写的。
正如一个好的Scrum团队应做到的，这个负责网络应用的团队的目标是：在每个Sprint结束时递交一个潜在可交付的产品。他们将潜在可交付定义为：代码结构良好以及测试要做到他们非常确认没有遗留某个严重（会影响到财务）的缺陷的程度。这意味着需要写出最好的代码，并在该网络应用上增加和运行一套完整的自动化测试。在他们看来，这可以让该网络应用处于潜在可交付的状态。若想让潜在可交付达到真正可发布的程度，就可以临时安排某个发布Sprint：对该大型机应用执行三周的手工测试。
潜在可交付并不意味着系统功能的完整
仅仅因为说一个产品是潜在可交付，并不意味着有人要我们真的发布它。有时候以最低可用的方式为完整实现某个功能特性，需要花费两、三个或更多Sprint，但是即使在这种情况的实现过程中，团队仍然要努力让该产品在每个Sprint结束时达到潜在可交付的状态。
例如某个公司正在给他们的产品增加打印及其预览功能。在Sprint计划会议上，团队确定他们不能在一个Sprint中同时增加打印及其预览功能。于是在产品负责人同意下，团队选择首先实现预览功能。在Sprint结束时，他们成功地完成了打印的预览功能，该功能已很稳定：它的代码结构良好，彻底地被测试过以及产品可以带着它发布。然而，有谁会要一个只有打印预览而没有打印功能的产品呢？但是在第一个Sprint后的这个完整功能特性的部分缺失并不妨碍该产品是潜在可交付的。如果有人想只要打印预览功能，那么该产品就可以发布。
潜在可交付意味着集成已做好
潜在可交付的产品不应该出现还有14份不同的源代码需要集成的状态。在多个团队的项目中，团队必须在“已完成”的定义标准中包含集成开发代码流，更进一步说，集成必须在Sprint中被持续地完成。
刚接触Scrum的开发人员经常认为：在有足够数量的应用程序代码已被开发后，迭代和增量开发看起来是可行的，但是在这之前是不可能的。作者不同意这点。即使基础的组件也可以增量构建。在最初的几个Sprint，大部分或全部集中在产品的基础方面的工作常常是必要的。我承认通常很难找到合适的方法，给最终用户演示这部分工作的价值。但是有时是可以做到，特别是在项目早期。仅仅因为某些东西很难不是直接放弃它的理由，相反，我们应找到方法将那些早期的系统基础部分拆分到更小的工作，以便它们适合在一个Sprint中实现。我常做的一种方法是考虑平时很自然的功能小点，比如我直接叫一个同事并跟他说：“嘿，请从代码库中切出并看一看我刚做的又酷又新的工作”，只要该工作可以让该同事提供反馈信息即可（那怕只是类似“不错”的正面肯定）。对于某个早期的Sprint，还是可以找到相当多的功能小点适合这么做。
即使团队早期那些Sprint中包含某些对用户或客户有可见价值的内容，也请找到这些自然的功能小点。
作者:Mike Cohn
