目前User Story初稿由PO根据客户的需求来编写，AC点作为故事的一部分对故事进行说明。然后通过Pb grooming、计划会等过程，与团队共同review，补充完善。

    然而，实际的迭代实施中，需求的传递并不总是顺利的。迭代发布计划会上，POs经常会遇到团队的质疑“你这个Story的AC点为什么没有写这个逻辑？”“你应该在AC点里补充提示语是什么”“超长的处理逻辑需要在每个故事AC点提现下，要不我们怎么知道要不要写测试案例（TC）？”“计划会时也没说（或者不记得了）要做这个呀”。每日站会上，团队成员A：“昨天我完成了故事1！今天我将开始工作于故事2上。”两天后，PO找到团队，“故事1怎么回事，这个流程和我想要的并不一样……”。

    AC点是……

    作为承担需求澄清责任的AC点到底应该怎么写，才能做到“让团队满意”又“不漏不重不冗余”呢？

    首先，我们来看下AC点是什么。AC全称Acceptance Criteria，又名“验收准则”，是PO检验user story完成度的重要衡量指标。AC一般作为User story（用户故事）卡的一个重要组成部分出现，针对user story内容进行说明和解释。每一条AC都应体现出业务价值，是story的功能集，是story交付时必须满足的一组条件。

    AC点辅助团队理解需求，提高需求质量，减少理解不一致造成的分歧、返工。AC还可以控制Story可以完成什么，不用完成什么，甚至该怎么完成。

    AC点不是……

      User Story的INVEST原则有一条就是“可讨论的（Negotiable）”：故事卡是功能的简短描述，细节在客户团队和开发团队的讨论中产出。也就是说，用户故事不是确定不变的详细设计说明书，AC点也不是大而全的详细设计，AC点只故事完成的必要的条件。AC点内容也只是关于关键或重要事情的简短描述，用以提醒团队和PO进行关于此项内容对话。

      AC点不是澄清User story的唯一工具，PO还可能需要通过UI效果图及切图确定页面布局、流程图或交互图说明交互流程、提示语列表定义系统文案等使所有人对User story的理解达成一致。

     比如我们在计划会中，PO讲解故事“修改LOGO”时，除了提供故事卡以外，还会提供UI图，开发团队提供（或经讨论）形成各种异常情况的处理策略及提示语。

    AC与TC关系

    Test Cases（测试案例）也是User story的一个重要补充，是AC的具体实现。TC应该比AC更加详细，不止包括AC的所有内容，还应包括很多异常测试用例，以确保系统对异常能正确的处理。 比如AC点“用户名长度为10个字符以内”，那么TC就需要至少包括以下场景。

    在讨论中产生很多细节设计，也都建议都通过TC明确，以防后续被遗忘。还以前面的“修改LOGO”为例，在实施中讨论到“允许上传图片的大小限制应该是多少？”这个问题对客户不敏感，但对代码健壮性缺不可或缺。就需要在确定后，建立一条TC，以保证实施结果与与预期一致。

    AC点中没有写到的内容，若开发未实现，故事算完成了吗？

    从《Scrum 指南》对Story”完成"的2层定义我们可以找到答案：

（1）满足DOD（Definition of Done）。DOD可以是开发组织的惯例、标准或指南，也可以是适用于本团队的定制约定。比如需要所有测试案例都通过，代码都走查过，仪表盘显示都通过等。

（2）基于所有人对User story的理解一致的基础上，满足所有AC点。 比如，检查AC点是否满足前需要先确定前端页面与UI设计一致，异常情况处理符合系统规约等。

       实战中，我们需要先定义所有人理解一致的”完成”定义，再建立良好的沟通氛围，促进整个团队对需求的思考，而不是单向的接收需求。迭代结束时，再由PO最终决定故事是否完成。

最后的最后

    敏捷强调是沟通，合作，User story从编写开始就需要严格遵守INVEST原则，范围不能模糊不清、漫无边际，PO作为User story的唯一负责人需要在AC点中说明关键要素，帮助团队正确理解需求。