在这篇文章中，我们将介绍如何编写好的用户故事以及应该包含哪些内容。
用户故事代表一小部分功能，具有团队可以在冲刺中提供的业务价值。用户故事和传统需求文档之间的区别在于详细程度。
需求文档往往包含大量文本并且非常详细，而用户故事主要基于会话。
我们可以将用户故事的结构分解为：
- 需要的简要说明
- 在积压修饰和sprint计划期间发生的对话以巩固细节
- 确认故事圆满完成的验收测试
在编写用户故事时要记住的一个重点是，它们是从最终使用该产品的用户的角度编写的，因此在编写用户故事时我们必须清楚地识别用户是谁。
如何写好用户故事
根据经验，一个好的用户故事应该遵循INVEST的缩写：
I ndependent - 用户故事不应该相互依赖，因此它们可以按任何顺序开发。
N egotiable - 避免太多细节; 保持灵活性，以便团队可以调整实施的故事数量。
V aluable - 故事应该为其用户提供一些价值。
E stimable - 团队必须能够估计故事。
S商城 - 用户故事应足够小，以适应冲刺; 大型故事很难估计和计划。
T estable - 确保正在开发的内容可以得到充分验证和测试。
用于编写用户故事的格式是什么？
用户故事通常具有以下格式：
作为<用户类型>，我想<feature>以便<benefit>。
示例：
作为 abc.com 的客户，我想要一个登录功能，以便我可以在线访问我的帐户详细信息。As a customer of abc.com, I want a login functionality so that I can access my account details online.
如前所述，要特别注意产品的用户是谁，并避免“用户”的一般角色。如果你不知道谁是用户和客户，以及为什么他们会想要使用的产品，那么你应该没有写任何用户故事。
叙述
- 用户故事的第一部分是叙事。用2-3个句子来描述故事的意图。这只是意图的总结。
对话
- 用户故事最关键的方面是开发团队，客户，产品负责人和其他利益相关者之间应该不断进行的对话，以巩固用户故事的细节。
验收标准
- 验收标准代表满意的条件，这些条件被写为场景，通常采用Gherkin（Given，When，Then）格式。验收标准还提供故事的完成定义。
谁应该写用户故事？
在大多数情况下，用户故事由产品负责人或业务分析师编写，并在产品待办事项中进行优先级排序。但是，这并不是说只有产品负责人才能编写用户故事。实际上，任何团队成员都可以编写用户故事，但产品负责人有责任确保存在积压的用户故事并确定其优先级。
重要的是，用户故事不应该被视为需求文档，在撰写时将被交给开发团队实施。
用户故事应被视为鼓励产品负责人和开发团队之间进行对话的一种手段，因此应在产品待办事项修饰会话期间进行协作编写。
让开发团队参与编写用户故事的一个优点是，如果存在任何技术限制，可以提前突出显示它们。测试人员可以特别增加构建有效验收标准的价值，并提前计划需要测试的内容和方法。
用户故事的详细程度如何？
用户故事关注客户价值。
用户故事与其他形式的需求规范之间的基本区别在于详细程度。用户故事是正在进行的工作的隐喻，而不是对工作的完整描述。随着系统开发的进展，通过协作围绕用户故事进行充实的实际工作。
如果描述变得过于冗长（超过索引卡上的描述），您应该重新访问用户故事。您可能想要包含太多细节。
请记住，用户故事的目的是鼓励协作。它并不意味着记录工作的每个方面，因为传统的需求声明通常就是这种情况。
此外，描述中的过多信息可能导致接受标准中缺少信息。
在同意处理故事之前，团队必须了解验收标准。这些对于了解需要做什么以满足用户故事至关重要。接受标准应该足够详细，以定义用户故事何时满足，但不是那么详细，以至于无法进行协作。
编写用户故事时常见的错误
- 太正式或太多细节。 有良好意图的产品所有者经常尝试编写非常详细的用户故事。如果团队在迭代计划中看到一个看起来像IEEE需求文档的故事，他们通常会认为所有细节都在那里并且将跳过详细的对话。
- 编写技术任务的用户故事。 敏捷的大部分功能来自于每次迭代结束时软件的工作增量。如果您的故事实际上只是技术任务，那么在每次迭代结束时，您通常不会使用工作软件，并且在优先级排序方面会失去灵活性。
- 跳过对话。 在迭代计划之前，故事是故意模糊的。如果您跳过验收标准对话，则可能会向错误的方向移动，缺少边缘情况或忽略客户需求。
敏捷软件开发
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。