如何写好用户故事

用户故事有点像一把双刃剑。如果写得正确，他们可以为您的团队提供不同的视角，帮助他们了解运送质量特征所需的复杂性。

另一方面，定义不明确且不明确的用户故事可能会打开你并引起团队内部的误解。更不用说，还有必须编写“故事”而不是功能要求的问题。

不完全是每当您向团队提出要求时，他们可能很难理解该功能应该做什么。他们带来了他们认为应该添加的更多功能，只为你重复一句“但那不是用户想要的”

如果操作正确，用户故事可让您的团队专注于满足用户的需求。并阻止你构建一个笨重，混乱的软件。

那么，你如何写一个好的用户故事？

用户故事简短，简单描述了如何使用功能。它们是用非正式的自然语言编写的，从用户的角度来反映他们的需求以及他们打算通过使用您的功能实现的目标。

这意味着用户故事不应包含有关如何构建功能的技术细节，也不应包含功能规范。顾名思义，他们将只有一个故事，说明为什么您的用户将使用某个功能并获得什么好处。

如果您考虑一下，您构建的每个功能都与高级功能无关，而与满足用户需求有关。

一旦您收集了有关您的用户，他们的需求以及他们的目标的足够信息，编写用户故事可能看起来很简单。

但是当功能的质量出现并且取决于你如何定义用户故事时，你不能简单地坐下来希望最好，你呢？

将您的用户故事从优秀转变为优秀的五件事

1.用户故事彼此独立

您编写的每个用户故事都应该彼此独立。如果您认为一个用户故事依赖于另一个用户故事，那么您已经将故事细分了。同样，如果您的用户故事过于宽泛，则很可能是一部史诗。

保持用户故事彼此独立可以帮助您确定积压的优先顺序。当依赖关系发挥作用时，如果不实现其他价值低得多的故事，可能无法实现有价值的故事。

简而言之，用户故事本身应该是用户可以使用并从中获取价值的有用功能。

2.不要将用户故事与任务混淆

用户故事可能包含多个任务和子任务。但用户故事本身并不是一项任务。

任务和子任务是关于更精细的细节。他们是关于实施。您的功能的“如何执行它”。另一方面，用户故事保持在元级别;它讨论了为什么以及你的功能。

3.为用户提供价值

您的用户的痛苦与他们今天的解决方案之间的差距是您的功能真正的游乐场。如果您的用户故事不会填补这些空白，那么您最好不要使用它们。此外，您是否愿意为您的业务开展一项功能？或者在用户几乎找不到价值的东西上工作？

您优先考虑和处理的每个用户故事都应该为您的客户提供一些价值并解决问题。

“但是科技债务，错误和改进呢？”，我听到你问。

技术债务和改进在您的产品积压中占有一席之地，并且必须优先考虑。否则，您最终将构建一个缓慢且有缺陷的遗留软件。但它们不是用户故事，除非它们为您的用户提供实际价值。

例如，如果您使用Zepel，则可以将您的技术债务和改进添加为增强功能。当然还有用户故事，错误和任务（以及子任务）。

Zepel4中的用户故事，增强功能，错误和任务列表。他们是可以谈判的

由于用户故事不讨论实现，因此应该留出讨论空间，因此当您与团队协作时，每个人都可以讨论并就如何实现该功能的具体内容达成一致。

这样，您的团队就可以了解所涉及的复杂性，并提出创造性的实施方法，而不必局限于特定的方法。

足够大，可以分解成任务和估计

您现在可能在您的待办事项上有大量用户故事，并想知道如何优先考虑另一个用户故事以及过滤掉哪些用户故事。

第一直觉是从你的积压中丢弃物品开始，我明白了。但是，最好先将用户故事分解为可操作的任务块并在丢弃之前先估算用户故事。

通过估计您的用户故事可能需要多长时间，您可以与您的团队合作，找出所需的最低功能集，以帮助您的用户解决问题并实现目标。

用于编写完美用户故事的模板

编写一个用户故事，团队中的每个人都能理解，简单，并且没有技术细节就很难了。你越远离用户的角度谈论，你将添加的细节越多，对你和你的团队来说就越少。

幸运的是，您可以使用以下模板编写用户故事并团结您的团队，专注于一个真正的原因 – 解决用户的问题。

1.角色 – 特征 – 原因格式

当它在英国的Connextra创建时，也被称为Connextra格式，以表彰它的起源。

作为（角色）我可以（能力），以便（获得利益）

2.编写用户故事的另一个版本

作为（特定用户），我想（能够执行/做某事）以便（我获得某种形式的价值或利益）。

互联网上有几个模板可以帮助您编写用户故事。但在其核心，不仅要写一个好的，而且是一个伟大的用户故事，你需要定义三件事：

1.用户角色：即将使用该功能的人。人物角色通常是基于真实数据开发的虚构角色。

2.角色的需要：用户角色想要做什么，或者他们想要什么功能/特征。

3.角色的目标：为什么他们需要特定的功能/特性以及他们希望从中获得什么好处。

困难的部分是让这3个数据点准确。您需要进行研究，与用户交谈并了解他们的需求。收集到足够的信息后，您应该可以通过填写此模板来编写用户故事：

作为（角色），我想（需要）以便（目标）。

但是编写用户故事有什么好处？

通过可靠的用户故事，您可以在与团队协作时将通信锚定到对用户最重要的事情上。您可以通过“对我的用户如何重要？”的简单过滤器传递您所做的每项功能，功能和活动。

用户故事的核心优势可以归结为以下四个要点：

1.他们将注意力中心化在用户身上

如果您希望完成重复性工作并保持团队专注，那么任务和子任务列表都很棒。但是，当您想要构建能够解决用户问题并满足其迫切需求的产品时，您需要让您的团队专注于您的用户。不是清单。

每个故事都中心化在您的客户身上，您的团队将更轻松地专注于重要的事情 – 您的用户需求

“从某种意义上说，只有一个错误可以杀死创业公司：没有做出用户想要的东西。”
〜保罗格雷厄姆

他们帮助确定关键功能的优先顺序

还记得你的QA团队在第11个小时来找你的时候有一个突然出现的错误吗？

团队中的每个人都充满热情，迫不及待地想要看到这个新功能投入生产。您的开发人员正准备部署。您需要决定是否应该解决问题然后进行部署。或者，如果你应该部署bug。你是做什么？

当然，如果bug是一个showstopper，你别无选择，只能在部署之前修复它。但是那些不足以阻止整个部署的错误呢？

这很难，不是吗？

只要问问自己，错误是否会阻止用户实现目标可以帮助您更好地确定优先级。

当敲门时要求添加到现有功能中时，同样的原理可应用于增强功能。

相关阅读：如何确定正确功能的优先顺序
优先考虑正确的功能是一个巨大的痛苦。了解如何确定正确的功能集的优先级。 blog.zepel.io 3.使非技术成员能够进行贡献和协作

构建现代软件很复杂。它涉及广泛的技术和实施过程，可能会使团队中的其他成员感到困惑。

由于用户故事是用简单的非技术语言编写的，因此它可以帮助组织中其他功能的成员像设计师一样提出想法并帮助决定如何最好地为用户服务。

4.着重解决问题

很容易直接进入并淹没在充满可行思路的矿池中，而不是退后一步，专注于问题本身。

从“什么”开始 – 解决方案 – 创建防守团队。但是当你从“为什么”开始 – 问题 – 你可以围绕一个问题团结你的团队，并提出创造性的方法来解决手头的问题。

使用“接受标准”定义用户故事的完成时间

验收标准允许您定义用户故事何时完成，并具有满足用户需求所需的所有功能。

它们是用户故事应该满足的一组条件，以便被视为已完成。它提供了用户故事的详细范围以及所需的内容，以便您的团队了解他们的反对意见。这样，每次发布新功能时，您都可以确保该功能符合用户应得的标准。

但是，在您热情地声明用户故事应该满足的一组功能标准之前，请考虑其他变量如何影响功能的质量并将其包含在您的验收标准中。

验收标准可包括：

1.用户体验

2.当前用户故事对现有功能的影响

3.速度等关键性能

4.该功能的目的是什么

注意：与用户故事一样，验收标准不是任务。
它们是一种向用户故事添加功能细节的技术。

因此，根据您正在构建的功能及其复杂性，与您的团队坐在一起，找出它应该执行的最低功能子集以及它应该如何运行。如果它是产品的复杂或核心功能，您应该考虑编写尽可能多的详细验收标准，以帮助您的团队避免任何混淆。

用于编写验收标准的模板

为了简化生活，这里有一个简单的模板，可用于编写验收标准：

给定（上下文）何时（执行特定操作）然后（应该发生一系列后果）

验收标准的示例：当我输入用户名和密码登录时，我在登录页面上，然后我将被带到“我的仪表板”页面。

在Zepel中，我们建议用户将所有验收标准添加为用户故事的描述，因此当您的团队成员选择它时，他们可以全面了解完成用户故事所需的内容及其相关讨论。

Zepel中的用户故事和接受标准

结论

项目管理行业的数字化标准化了任务和问题的使用。只要你想完成一些杂务并修复一些问题，它们就可以正常工作。

但是，如果您正在尝试构建一个不仅能满足用户需求而又能解决问题的产品，那么您需要让团队专注于用户的痛点和目标。

通过使用用户故事，您可以描述开发团队日常工作背后的“原因”（以及“内容”），并确保他们不会检查项目管理工具中的大量工作项。但是要努力构建用户需要的功能并为您的业务提供支持。

正如您可能已经猜到的那样，本文对我们和我们的工具来说有点插件。因此，下次构建新功能时，请在开始添加任务之前启动Zepel并尝试创建用户素材。

最初于2019年5月9日在https://blog.zepel.io上发表。