编写用户故事模板_编写用户故事时，您的团队可能会犯错误-以及如何解决它们

编写用户故事模板

There's a lot of information out there on how to write user stories and why it's important. And yet, many of us make mistakes that cost us a lot.

关于如何编写用户故事及其重要性的信息很多。 然而，我们许多人犯的错误使我们付出了很多代价。

There are many who even prefer an alternative method. (Here’s another one.) And it's often because they're frustrated by poorly written user stories.

许多人甚至更喜欢替代方法 。 ( 这是另一个 。)通常是因为他们对用户故事写得不好而感到沮丧。

As much as it's important to know how to write good user stories, it's equally important to know how to NOT write one.

知道如何编写良好的用户故事很重要，但是知道如何不编写一个用户故事也同样重要。

Today, many software teams want to adopt agile processes. They want to put the user in the center of their product development process while building products. And it makes perfect sense. After all, you are building the product for your users, right?

如今，许多软件团队都希望采用敏捷流程。 他们希望在构建产品时将用户置于产品开发过程的中心。 这是很有意义的。 毕竟，您是在为用户构建产品，对吗？

A lot of times when writing user stories we think we are writing from the user’s perspective, but we end up skewing it with our biases and knowledge. And a lot of times, these mistakes are interlinked and only get worse with time.

很多时候，在编写用户故事时，我们认为我们是从用户的角度进行写作的，但最终我们因偏见和知识而歪曲了。 在很多情况下，这些错误是相互关联的，并且随着时间的推移只会变得更糟。

In this article I will talk about some of the common mistakes teams make when writing user stories.

在本文中，我将讨论团队在编写用户故事时常犯的一些错误。

用户故事过于广泛 (User stories that are too broad)

When user stories are too broad, crucial information regarding the expected action and the need can get missed. If there are a lot of “ands” or “ors” or "thats" in your team’s user stories, it is good indication that it is too broad and you should consider re-writing it.

当用户故事过于广泛时，可能会错过有关预期操作和需求的关键信息。 如果团队的用户案例中有很多“ and ”，“ ors ”或“ thats ”，则表明它太宽泛了，您应该考虑重写它。

Also, there’s a very good chance that your too broadly written user story is actually an epic.

同样，您写得太宽泛的用户故事很有可能是史诗级的 。

An example of a broad user story might look like this:

一个广泛的用户故事示例可能如下所示：

“As a user, I would like to continue reading the article later when I’m on my way home, without needing to sign up and find the exact spot where I left off.”

“ 作为用户，我想在以后回家的路上继续阅读文章，而无需注册并找到我上次离开的确切地点。 ”

In this case you can see the user story is trying to achieve two things — not needing to sign up and not having to find where they stopped reading. Instead of trying to cram everything into a single user story, consider breaking it down into multiple user stories.

在这种情况下，您可以看到用户故事正在尝试实现两件事–无需注册以及不必查找他们停止阅读的位置。 与其尝试将所有内容填充为单个用户故事，不如将其分解为多个用户故事。

Here's how it may look after it is broken down:

分解后的外观如下：

"As a user, I would like to continue reading the article later without having to sign up"

“ 作为用户，我希望以后无需注册即可继续阅读文章 ”

"As a user, I want to continue reading from where I left off, so that I don't have to find the last paragraph I finished reading"

“ 作为用户，我想从上次停下来的地方继续阅读，这样我就不必找到我读完的最后一段 ”

用户故事太好了 (User stories that are too fine)

When user stories are broken down into too much detail, you begin talking about how you are going to implement it. This removes the focus from the user and leads to poor communication of expectations within the team.

当用户故事分解为太多细节时，您将开始讨论如何实现它。 这消除了用户的注意力，导致团队内部的期望沟通不畅。

Here's an example of a user story that is defined too fine that it talks about implementation details.

这是一个用户故事的示例，定义得太精细，以至于无法讨论实现细节。

“Define a scalable, relational database structure so that I can use it to implement any possible future use case.”

“ 定义一个可伸缩的关系数据库结构，以便我可以用它来实现将来任何可能的用例。 ”

What business value does a great relational database have if the end user cannot use it? Besides, this user story is written from the business' perspective and not from the user's perspective. When you begin to include the implementation details, user stories no longer are written from the user's perspective.

如果最终用户不能使用一个好的关系数据库，它具有什么商业价值？ 此外，此用户故事是从业务角度而不是从用户角度编写的。 当您开始包括实现细节时，不再从用户的角度来编写用户故事。

不可谈判的用户故事 (User stories that aren't negotiable)

User stories are not meant to be specific, precise descriptions of a feature. And therefore, they must not be fixed in stone.

用户故事并不意味着对功能的特定而精确的描述。 因此，它们一定不能一成不变。

Here's an example of a non-negotiable user story: "As a user, I want to have a clear all button in the notifications tab, so I can remove old notifications"

这是一个不可商议的用户案例的示例：“ 作为用户，我想在通知选项卡中有一个清除所有按钮，以便删除旧的通知 ”

You can clearly see, the user wants to be able to remove old notifications. While having a "clear all" button is one solution, you can still automatically clear the notification after it's read too!

您可以清楚地看到，用户希望能够删除旧的通知。 虽然拥有“清除所有”按钮是一种解决方案，但是您仍然可以在读取通知后自动清除它！

Here’s a classic scenario to help you identify if your user stories are too rigid:

这是一个经典方案，可以帮助您确定用户故事是否过于僵化：

Sometimes a user story may have been written in a particular way, and your team finds it hard to implement because there’s an easier alternative.

有时，用户故事可能是用特定的方式编写的，而您的团队发现很难实现，因为有一个更简单的选择。

In cases like these, the team should be willing to compromise on the approach provided it doesn’t hurt the value a user derives.

在这种情况下，只要不损害用户获得的价值，团队就应该愿意妥协。

接受条件中重申的用户案例 (User stories that are reiterated in acceptance criteria)

Far too many times I notice the acceptance criteria repeating the user story, just in different words.

我发现太多次接受准则重复了用户故事，只是用了不同的词。

Here's how it looks:

外观如下：

User story: "As a user, I want to add pop-up forms to my blog, so I can capture the visitor's email id before they leave the site"

用户故事： “ 作为用户，我想在我的博客中添加弹出式表单，以便在访问者离开站点之前捕获其电子邮件ID ”

Acceptance criteria: "Given a reader visits a blog, when they try to leave, then the pop-up form should come asking them to subscribe to the blog"

接受标准： “ 假设读者访问博客，当他们尝试离开时，弹出表格应要求他们订阅博客 ”

Acceptance criteria should communicate the conditions that need to be met for the story to be marked as completed. This ensures that you gather feedback, help the team plan, and track their work. It makes the user story richer, more precise, and more easily testable. And more importantly, it aligns your team on what they're expected to deliver.

验收标准应传达将故事标记为完成所需的条件。 这样可以确保您收集反馈，帮助团队计划并跟踪他们的工作。 它使用户故事更丰富，更精确，更易于测试。 更重要的是，它可以使您的团队与他们期望的目标保持一致。

Here's a better example:

这是一个更好的例子：

For the user story: "As a user, I want to receive notifications when others add comments so that I am up-to-date."

对于用户故事： “ 作为用户，我想在其他人添加评论时接收通知，以便我保持最新状态。 ”

Acceptance criteria: "Given I have the app open when I am writing on the doc then the bell icon should update to show unread notifications with count"

接受标准： “ 在我在文档上书写时，假设我已打开应用程序，则响铃图标应更新以显示带有count的未读通知 ”

具有未定义用户的用户故事 (User stories that have an undefined user)

It can feel silly to mention the user persona in every user story over and over and over. However, it can add a tremendous amount of value in terms of the outcome.

一遍又一遍地在每个用户故事中提及用户角色可能会很愚蠢。 但是，它可以在结果方面增加巨大的价值。

This is particularly important if your product has more than one user persona. There will, of course, be features that’ll get built specific to different personas. If you want your team to be more aligned on the outcome you are expecting out of them, they need to know who the end users are and what benefit they’ll get out of the feature.

如果您的产品具有多个用户角色，这尤其重要。 当然，将有一些特定于不同角色的功能。 如果您希望您的团队对期望的结果更加一致，则他们需要知道最终用户是谁，以及他们将从功能中获得什么好处。

If you're looking for an example for this, nearly all examples I provided above are great ones of how not to do. Don't worry, it was intentional so I can talk about this. :)

如果您正在寻找一个示例，那么上面我提供的几乎所有示例都是很好的示例。 别担心，这是故意的，所以我可以谈谈。 :)

Every time you write a user story that begins with "As a user..." or "As a visitor..." or "As a reader...", you're leaving room for ambiguity. Clearly defining who that person is will go a long way in giving your team the context they require.

每次您编写以“ 作为用户... ”或“ 作为访客... ”或“ 作为读者... ”开头的用户故事时，您都会留下歧义。 清楚地定义此人是谁，可以为您的团队提供所需的背景。

At Zepel, we recommend writing the persona instead of user/visitor/reader. This means, your user story will look like this:

在Zepel ，我们建议编写角色而不是用户/访问者/阅读者。 这意味着，您的用户故事将如下所示：

"As a writer, I want to receive notification when others add comments within the Google Docs app, so I don't have to refresh the page every now-and-then"

“ 作为一名作家，当其他人在Google Docs应用程序中添加评论时，我希望收到通知，因此我不必每次都刷新页面 ”

用户故事背景不佳 (User stories with poor context)

Far too many times, we end up writing user stories just for the sake of it. After a certain point, nearly every user story starts to look the same.

太多次，我们最终只是为了它而写用户故事。 在某一点之后，几乎每个用户故事都开始看起来相同。

Here's an example: "As a content manager, I want a text editor so that I can edit text."

这是一个示例：“ 作为内容管理员，我想要一个文本编辑器以便可以编辑文本。 ”

All this tells your team is that you want them to build a text editor and nothing else. If you’ve been writing down a bunch of user stories for a while, it’s best to take a break and revisit it with a fresh perspective.

这一切告诉您的团队，您希望他们建立一个文本编辑器，而没有其他任何事情。 如果您已经写下了一段时间的用户故事，那么最好稍事休息，并以崭新的视角重新审视它。

Sometimes, even after a break, you might not be able to come up with something more meaningful. This can be a good indicator that you need to talk to your users more and understand their needs better. There’s really no point trying to squeeze it out of your brain.

有时，即使休息一会儿，您也可能无法提出更有意义的建议。 这可以很好地表明您需要与用户进行更多交流，并更好地了解他们的需求。 真的没有必要将其从大脑中挤出来。

结论 (Conclusion)

Although using a user story template can be useful, it is never as simple as completing a fill-in-the-blanks form in your agile tool.

尽管使用用户故事模板可能很有用，但它从来没有像在敏捷工具中填写空白表格那样简单。

Because one mistake while writing user stories often leads to a series of other mistakes as a by-product. And even if you do manage to write user stories properly, it’s only the beginning. You should still enable your to team to analyze the stories — from a technical point of view — to help them estimate and create the necessary next steps.

因为在编写用户故事时出现一个错误通常会导致一系列其他错误，这些错误是副产品。 即使您确实设法正确编写了用户故事，这也仅仅是开始。 您仍然应该使您的团队能够从技术角度分析这些故事，以帮助他们估计并制定必要的后续步骤。

翻译自: https://www.freecodecamp.org/news/user-story-mistakes/

编写用户故事模板