验收标准(Acceptance Criteria)是用来做什么的？完成定义(Definition of Done)和验收标准有什么区别。谁应该对他们负责？他们是用在哪个级别？用户故事？Sprint，还是Release？如何构建他们？平时工作中PO、Team总会遇到一些混淆。本文是Scrum Alliance上的一片文章，正好解释了这些问题，希望能帮助小伙伴们更好的理解和应用到实际工作中。
正文
当您创建、构建或开发产品时——无论是软件、营销活动还是其他东西——您如何知道您所做的产品满足了客户的期望？输入验收标准：客户、Product Owner或干系人接受您所做的工作所需的条件。
这些标准不是Scrum框架所固有的，但许多Scrum和敏捷团队使用它们来组织工作并交付令人愉悦的结果。
定义验收标准
验收标准(Acceptance Criteria)被定义为产品、用户故事或工作增量必须满足的条件。
也可以缩写为AC，这些条件是通过/失败。验收标准要么满足，要么不满足；它们永远不会只有部分满足。
AC通常用一组语句来表达。他们应该是：
- 清晰，以便每个人都能理解他们
- 简洁，这样就不会模棱两可
- 可测试或可验证
- 专注于提供令客户愉悦的结果
验收标准并不关注“如何”达成解决方案或“如何”做出某事。相反，他们描述了你正在做的工作是“什么”。例如，标准可能是：
用户可以在结账时使用Google Pay或Apple Pay付款。
验收标准的精髓不是告诉你如何去做，例如：
安装一个Wordpress插件，允许您创建结账页面。
或者-
编写HTML，使使用Apple Pay或Google Pay付款成为可能。
这些描述了工作将如何完成，而不是验收工作成果的条件。应该由Scrum团队的开发人员决定如何满足验收标准。
正式规定的验收标准的敏捷实践始于软件开发，但今天，除了从应用程序开发到人力资源部门等不同行业的软件产品外，它们还应用于各种可交付成果。
验收标准与用户故事：有什么区别？
对于许多Scrum团队来说，用户故事是产品增量中最小的工作块，通常表现在特定的产品backlog上。您的团队可能会使用用户故事以外的东西来定义用户的问题陈述或目标，您不必使用用户故事来编写验收标准。
验收标准与用户故事不同。相反，它们相辅相成。
用户故事是从客户的角度对客户需求的简要描述。它描述了他们试图解决的目标或问题。验收标准是解决他们的问题或实现他们目标应该做的事情。
通过这种方式，用户故事描述了工作的“原因”，而验收标准描述了“结果是什么”。“如何实现”由开发人员在每个sprint中决定。
谁应该写验收标准？
您的客户希望、期望或需要从您正在做的产品中获得什么？这个问题的答案将帮助我们确定验收标准。毕竟，我们的目标是让客户满意。
因为我们都在不同的的行业和工作场景中工作，所以验收标准并不总是来自传统客户。相反，它可能是您的Product Owner或干系人的标准，也可能是其他类型的客户或用户的标准。
可用于创建验收标准的流程
定义验收标准的一些机会包括：
- 与客户或用户的讨论
- 与干系人的讨论
- 在Scrum梳理会活动期间
- 在Scrum冲刺计划活动期间
- 在产品backlog管理活动中
- 在团队头脑风暴中
- 评估客户或最终用户反馈后
在Scrum团队中，Product Owner通常负责编写这些验收条件；但是，开发团队可以也应该参与其中，提供他们的专业知识和反馈，同时与Product Owner的期望保持一致。
团队的Scrum Master可以通过寻找标准的潜在歧义来支持该过程，帮助团队了解AC的目的，并鼓励开发人员在标准不明确时及时举手提出异议。
在这些方面，确实可以通过团队的努力，让验收条件保持更接近客户一开始的期待。
你应该什么时候写验收标准？
在Scrum中，我们不断讨论产品product backlog条目，作为规划和改进活动的一部分。初始标准通常在backlog梳理会期间确定；然而，最后的验收标准最好在开发开始前完成。
实时的确保验收标准确保持最新，包括客户的目标和期望。敲定标准的好时机是在冲刺计划活动期间。Scrum团队评审AC，讨论任何问题或澄清需求，并决定是否可以将工作带入冲刺。
如何编写验收标准
编写标准的模板化方法可以在互联网上找到。说到Scrum指南，没有指导，因为这些标准与Scrum的轻量级框架是分开的。尝试不同的格式——自定义或从模板中——看看什么适合您的团队。
使用项目符号列表、清单或验证列表。
许多团队只是使用项目符号列表。您可以轻松地生成列表，并将其放置在用户故事中或您在冲刺中组织工作的其他任何地方。
无论您是使用项目符号列表、表格、编号列表、简短描述还是便笺，自定义方法都可能是一个很好的选择。考虑将您的验收标准格式作为回顾会的主题，以便您可以检视并调整其对您的团队的有效性。
使用基于场景的模板。
其他敏捷团队将使用一种称为基于场景的格式，其中您使用公式：鉴于(Given)；当(When)；那么(Then)：
- 鉴于（一些给定的上下文或先决条件），当（我采取此行动），那么（这将是结果）
写作验收标准清单
- 让每个参与者都清楚
- 可以测试或验证
- 通过或失败（例如，不能完成50%）
- 关注结果，而不是如何实现结果
- 尽可能具体（快速加载页面 vs 3秒加载页面）
有哪些验收标准的例子？
1. 对于商店网站上的结账页面： 。
- PayPal、Google Pay、Apple Pay和所有主要信用卡都可用于完成交易
- 显示购物车项目
- 可以从购物车中删除项目
- 如果用户尚未登录，系统会提示用户登录
2. 对于即将举行的会议：
- 鉴于我是注册与会者
- 当我进入会议场地时
- 名牌标志会把我带到登记桌前
3. 对于通过电子邮件发送的水费账单：
- 显示应付金额
- 显示截止日期
- 显示可能的滞纳金
- 允许用户轻松登录和付款
- 让用户知道如何联系办公室提出问题或疑虑
4. 对于健康诊所的预约前文书工作：
- 鉴于我是现有的健康中心患者
- 当我在线预约时
- 我将以电子方式收到可填写的预约前文件
不良验收标准的例子
在现实世界中应用敏捷实践时，您应该在实验中感受到他的能量，看看到他的效果。但一般来说，你也能在下面看到为什么以某些方式写AC是无效的：
示例1
验收标准：
在线购物车使用复选框来选择您要删除的项目
解释：
这个标准可能会对您的开发团队有效，并且不太可能造成任何直接问题；然而，它在技术上告诉开发团队“如何”通过包含一个复选框来删除结账页面上的项目。
示例2
用户故事：
作为一名在线购物者，我希望能够在结账页面上，从购物车中删除商品，这样我就可以轻松地在最后一刻进行调整，而无需单击后退按钮。
验收标准：
在线购物车允许用户在结账页面上删除商品，当您查看商品详细信息页面时，您可以看到“快速购物”选项
解释：
从技术上讲，该标准超出了用户故事的范围。这可能会导致太多的工作被归入一个用户故事中。
关键要点
由于AC与敏捷和Scrum有关，在“好”和“坏”的写作验收标准之间总是有一些灰色地带。这个工具是给你做实验的。一个团队认为“糟糕”的东西可能对另一个团队及其客户很有效。
使用您的回顾会来检查验收标准如何与您正在使用的方法一起工作。必要时进行调整。
撰写验收标准时要避免的常见错误
虽然有很多方法可以根据您的团队和上下文自定义验收标准，但也有一些常见的陷阱往往与AC的目的背道而驰：
- 忽略用户视角
- 告诉开发人员“如何”完成这项工作
- 写作验收标准太早了
- 等待冲刺中的开发开始，以编写验收标准
- 标准很宽泛
- 标准很模糊
- 有很多繁琐的标准（大量可能表明您需要将工作分解成更小的部分）
大多数敏捷践行者发现，他们可以通过清楚地写下验收标准，同时关注用户体验和客户期望，从验收标准中获得最大利益。
验收标准与完成的定义
您可能想知道这些满足条件与完成（DoD）的定义有何不同。毕竟，一旦满足标准，产品backlog的工作就完成了，对吗？
虽然完成定义和验收标准都表明已完成状态，但它们并不完全相同。
完成定义通常表示为必须满足的语句列表，以便将工作称为可能发货或以其他方式宣布该工作完成。最大的区别是，相同的DoD适用于每个产品backlog，并且不会在项目之间发生变化。
每个产品backlog的验收标准却是不同的。
以下是完成定义（DoD）的一个例子：
- 代码已完成
- 已经测试
- 没有缺陷
- 已经上线
这是另一个：
- 品牌合规性
- 同行已评审
- 已通知干系人
有时，当提到验收标准时，团队会称某事为“完成”。如果术语造成混淆，在提及验收标准时，您可能需要考虑将工作称为“已接受”而不是“完成”。
验收标准对敏捷组织的价值
验收标准有利于敏捷团队和Scrum团队，因为标准：
- 从最终用户到Product Owner再到开发人员，建立清晰的理解线
- 让开发人员确切地知道他们在冲刺期间需要完成什么
- 可以快速简洁地创建、支持工作软件的价值，而不是全面的文档（同时，如果您的行业合规性需要，也可以提供文档）
- 创造清晰度并减少歧义，以便自管理的团队能够高效地完成工作
- 降低客户感到他们的期望未实现的几率
- 提供测试产品的标准
如果您还没有用过AC，请尝试与您的团队一起使用它们。您可能会发现，验收标准可以改善沟通和协作，并将您与客户的需求更紧密地联系起来。
原文引用
- Everything You Need to Know About Acceptance Criteria