用于记录客户和开发人员之间关于软件功能的讨论。
“用户故事代表卡中的客户要求，导致对话和确认。” ??罗恩杰弗里斯
以下是用于定义用户故事和验收标准的众所周知的模板。
价值陈述：作为（用户角色），我想（活动），以便（业务价值）
接受标准：给定（上下文），何时（执行行动），然后（可观察的后果）
以下是编写用户故事时要考虑的一些通用准则：
用户故事有三个方面：卡片，对话和确认（Ron Jeffries 2001）用户故事应表示对用户或系统所有者有价值的功能。用户故事应描述单个功能。用户故事应该有一个注释部分，其中记录了有关用户故事详细信息的对话。用户故事应该在故事点中具有估计（成本），其表示大小和复杂性。用户故事应根据其对客户的价值进行优先排序。良好用户故事的属性（INVEST）Mike Cohn在他的“用户故事应用”一书中指出了一个好的用户故事的六个基本属性。这些是：
独立的（Independent）
用户故事应该不依赖于其他用户故事。用户故事应该是自包含的。用户故事应按任何顺序完成和发布。当发生依赖关系时，应该以不同的方式组合或拆分用户故事。可面议（Negotiable）
用户故事不应该是合同义务，因为它们是可以协商的。用户故事应该是客户，开发人员和测试人员之间的协作谈判。有价值的（Valuable）
用户故事应该对软件的用户或所有者有价值。用户故事不仅仅对开发人员有价值。用户故事应明确定义客户/用户的利益，以帮助确定优先级。用户故事应由客户编写，以确保其对客户/用户有价值。可估计（Estimable）
用户故事应根据故事点进行估算。在开发团队估计用户故事之前，应该清楚地理解用户故事。在开发团队估算之前，用户故事应包含足够的详细信息。当开发团队缺乏领域知识时，用户故事可能无法估计。当开发团队缺乏技术知识时，用户故事可能无法估计。当用户故事太大时，用户故事可能无法估计。小的（Small）
用户故事应该尽可能小，同时仍然提供用户价值。用户故事应该能够适合一次迭代。对于大的用户故事将难以理解和估计。可测试的（Testable）
应通过测试验证用户故事，以证明它们已正确实施。用户故事应包含指导测试的故事接受标准。用户故事应该很容易进行单元测试。（技术实施）用户故事应该很容易接受测试。（行为的）用户故事应尽可能以自动方式进行测试。故事点规划改进的Fibonacci（0,1 / 2,1,2,3,5,8,13,20,40,100）T恤（xxs，xs，s，m，l，xl，xxl，）完成（DoD）的定义团队可以使用许多标准来定义他们的“完成定义”。这可确保团队提供在功能和质量方面完成的功能。Done的定义是可审核的核对表。以下是国防部的一系列可能标准和活动：
单位测试通过接受标准达成代码已审核通过功能测试非功能性要求产品负责人接受用户故事用户故事示例以下是用户故事的示例。
科恩，迈克。用户故事应用：敏捷软件开发。第1版，Addison Wesley Professional，2004年。Wake，William C. Extreme Programming Explored。Addison Wesley，2002。看到此处说明本文对你还是有帮助的，关于“用户故事指南”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
