要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。

面向客户价值设定验收标准

简单说，就是客户看到说“完成了”，才算完成了。

从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功能联合运行，前后数据完整一致才可以做到。在“敏捷产品管理”系列中，还会更加深入地探讨这个话题。

下面的例子，很好地表明了客户眼中的完成标准，它是EA（电子艺界，世界最大的游戏发行商和开发商之一）用于判断游戏中不同故事完成标准的。

—S =Sufficient for feedback. “可获得反馈的”（第一次能看得见的）
—Generally the firsttime something can be seen in software, however incomplete.
 
—W=Working. “能运行的”（能用，但是艺术性欠佳的）
—The functionality isbroadly in place but art work (e.g. graphical quality, UI) may be very lowfidelity or placeholder.
 
—T=Testable. “可提交玩家测试的”（可以交给玩家而不会破绽百出的）
—(by kids in ourcase). The software is sufficiently done to put it in front of people that havenot seen it before and for them to be able to use it with minimal intervention.
 
—A=Alpha. “可提交Alpha测试的” （改改BUG就可以上线的）
—Potentiallyshippable, likely needing some polish and bug fixing.
 
—G=Great. “完美的”（可以上线而且估计反响强烈的）
—Shippable and likelyto receive a great review score.
 
为什么要搞这么复杂呢？因为游戏中有些功能，在开发出来之前策划人员也说不明白怎样才是好，但又急于开发出来看看，因此会采用最低标准S，就是能用就行，不测试，不写文档，不做性能优化……而另外一些功能，则可能比较正式一些，比如需要给某些玩家看到的，就会选择T或A级别；而正式功能，则会选择G。
不同的公司，有不同的客户群，为了不同的目的，需要制定自己相应的完成标准。

客户价值与工程实践的映射

上面是一个完全面向客户价值编写的完成标准，看起来很好，但是实践起来开发人员很难把握。
其实，每个面向客户价值的标准，背后都有相应的工程标准。在熟悉之后，开发人员一望便知。比如下面是上述标准中S和W标准的工程实践描述：
 
—W能运行的 =
—编码完成 √
—单元测试 √
—手工功能测试 √
—压力测试
—可回归自动测试
使用手册
 
—S可获得反馈的 =
—编码完成 √
—单元测试
—手工功能测试
—压力测试
—可回归自动测试
—使用手册

使用方法

上述面向价值的描述及其工程实践映射，不是在迭代计划会上现场想的，而是早就在项目之初就在项目甚至组织层面设置好了的。

在迭代计划会上，PO每讲完一个故事，都会在团队估算前指出故事完成的标准，这样团队就知道是不是要花费额外的测试、优化等工作量了。

 

不过，即使事先约好完成标准，若PO与开发组分开一个月，仍然可能得到一个”惊喜“。这就需要下篇提到的用户故事的开发与跟进。