1. 用户故事的故事( 三 )

我们需要问自己：我们如何为客户提供价值就能在我们的故事完成后直接让他们使用新功能？
4）估算
通常越小越容易估算，越可测试越容易估算。为什么要估算？
如果我们能估算一个故事，就说明我们对它有足够的了解，它是可行的，我们不知道的事情就不去估算；如果我们不能估算我们的故事，它肯定需要更多的讨论，更多的细节，或者更多的研究。
5）小型
在敏捷开发中，它意味着适合一个冲刺，甚至更少；故事越小，越容易把握故事的内容，小的特征与有价值的特征关系非常密切。
如果你想把故事切成多个小故事，你需要确保所有的故事都能为用户提供价值；就像一块蛋糕，你在生日派对上为你的客人提供服务 – 所有的蛋糕都有所有层的味道，这就像我们的软件平台。
现在，想象一下，我们的彩票故事不适合在一次冲刺中完成。
我们可以做什么？也许可以分成2个小的故事，每个小的故事都可以为我们的用户提供价值。
第1个故事会检查是否中奖：作为一个彩民，我想在网站上输入我的彩票号码，以便检查我是否中奖。
标题可以是：彩民可以查询自己是否中奖。
第2个故事会查询中了多少钱，前提条件是有中奖号码：作为一个有中奖号码的彩民，我想在网站上输入我的彩票号码，以便查询我中了多少钱。
标题可以是：彩民可以查询自己中奖号码的奖金数额。
这样我们就可以在第1个故事完成后，更快地为用户提供价值；而且我们可以更快地了解有多少用户对使用新功能感兴趣。
6）测试
如果我们知道如何测试它，我们就会知道它何时完成。一个常见的做法是在故事中添加验收标准；这些都是一些用例，可以确定软件做的是它要做的事情。
验收标准提供了功能场景，测试部分包括检查边缘用例、“悲伤路径” 场景、非功能测试（如性能）等。
每个故事都有一些具体的验收标准来帮助团队把握新功能需要实现的目标；然后，是团队一致同意的完成标准，它规定了每个用户故事在上线前需要满足的一些通用标准。
我们先给彩票例子中的第1个故事添加一些验收标准：
作为一个彩民，我想在网站上输入我的彩票号码，以便检查我是否中奖。
验收标准可以是：

如果这个号码是中奖号码，用户应该看到一条信息：“今天是你的幸运日，你中奖了！”
如果该号码不是中奖号码，用户应该看到一条消息：“再试一次，我打赌下次你一定会赢！”

对于第2个故事：作为一个有中奖号码的彩民，我想在网站上输入我的彩票号码，以便查询我中了多少钱。
验收标准如下：

如果用户中奖了，中奖金额应该以货币格式显示。
用户只能查询过去30天的中奖号码等。

给定/当/然后是一种Gherkin语言格式，用于编写验收标准和自动化测试，它来源于行为驱动开发（BDD），例如：给定用户一个中奖号码，当用户在网站上输入该号码，然后中奖金额就会以货币格式显示。
如果你运行了一个带有自动测试的工具，比如Cucumber ，那就特别有用；同样，就像用户故事模板一样，这种格式是可选的。
完成标准：如果我们的彩票页面要求适配手机，并且有三种语言版本，这些通用要求可以作为我们完成标准的一部分。
四、总结篇
用户故事是为了鼓励团队内关于产品的对话，这些对话集中在三个最重要的事情上：谁会使用产品，他们会用它做什么，以及为什么。
拆分用户故事可能很复杂，但不用担心，你可以通过实践掌握它，有很多技巧也可以帮助你。
原文链接：
https://uxdesign.cc/the-story-of-user-stories-part-1-e1c8e4995f7f