编写用户故事模板
TL;DR Well-written user stories are the backbone of an efficient agile software development process. When done poorly, the wrong thing gets built and teams waste enormous amounts of time on costly rework. When done well, teams are able to confidently forge ahead knowing they’re building the right thing. Investing the time to write kick-ass user stories also provides transparency to those outside of the scrum team through clearly articulated value of the work they do and what (specifically) is being built.
TL; DR精心编写的用户故事是有效的敏捷软件开发过程的基础。 如果做得不好，就会犯错，团队会浪费大量时间进行昂贵的返工。 只要做得好，团队就能知道自己正在构建正确的东西，从而自信地前进。 花费时间编写无礼的用户故事还可以通过清楚地表达他们所做工作的价值以及正在构建的内容(具体而言)，为Scrum团队之外的人员提供透明度。
Poorly written user stories are pervasive in agile software development. Product owners know that acceptance criteria are important, but often write stories containing just a sentence or two of detail (if you’re lucky). Teams need more than this to properly prioritize them against other work in their product backlog, clearly understand the value of what they’re working on, feel confident that they’re building the right thing, and know when to call the story done. As the primary method of communicating what new functionality users desire, poor user stories often result in the wrong thing being built, ultimately leading to wasted time, effort, and money reworking issues.
在敏捷软件开发中普遍存在写得不好的用户故事。 产品负责人知道接受标准很重要，但是经常写只包含一两个句子的故事(如果幸运的话)。 团队不仅需要这些，还需要在产品积压工作中将其优先于其他工作，清楚地了解他们正在从事的工作的价值，对自己正在构建正确的事情充满信心，并知道何时完成任务。 作为通信有什么新的功能，用户希望的主要方法，较差的用户故事往往会导致错误的事情正在修建，最终导致浪费的时间，精力和金钱再加工的问题。
Let’s recap the original intent of user stories as a fundamental part of the Scrum process:
让我们回顾一下用户故事的初衷是Scrum流程的基本部分：
User stories are short descriptions of new system behavior told from the perspective of a — you guessed it — user! They represent:
用户故事是从用户(您猜对了)的角度讲述的新系统行为的简短描述！ 他们代表：
Placeholders for a Discussion — Between the product owner and development team. No amount of detail in the story can replace the conversation that must take place. It not only provides clarity of requirements but can also unearth new ideas to incorporate into the story, provide insight into technical feasibility and design options, and encourages discussion around scope and timeline tradeoffs.
讨论的占位符 -产品所有者和开发团队之间。 故事中没有任何细节可以代替必须进行的对话 。 它不仅可以使需求清晰明了，而且还可以发掘出新的想法以融入故事中，提供对技术可行性和设计选项的洞察力，并鼓励围绕范围和时间表进行权衡取舍。
Increments of Value — When complete, a user story should ultimately create business value by enhancing the user’s experience in some way. If it doesn’t do this, then why work on it?
价值增量 —完成后，用户故事应最终通过以某种方式增强用户体验来创造业务价值。 如果它不这样做，那为什么要继续做呢？
Anyone can write them — great ideas can come from anywhere, and most often come from those closest to the work. While the product owner is ultimately responsible for what the development team works on and when, everyone is responsible for ensuring only good user stories make it into a sprint, regardless of who originally wrote it.
任何人都可以编写它们-伟大的想法可以来自任何地方，并且通常来自与工作最接近的人。 虽然产品所有者是最终为了什么开发团队的作品上， 当负责， 人人负责确保只有良好的用户故事使之成为一个冲刺，不管是谁最初写的。
User stories contain:
用户故事包含：
A Description — Tells the world who the user story is being created for, what is being created, and why. This is most often presented in the format of As a <user persona> I want <some new functionality> so that <some value is created>.
A描述 -告诉谁是被用于，正在创建什么 ，以及为什么创建的用户故事世界。 这通常以“ <用户角色>”的格式显示。 我希望<某些新功能>，以便创建“某些值”。
Acceptance Criteria — Define the new system functionality, most commonly presented as a bullet-point list of independently testable system behaviors. These include both functional and non-functional requirements (performance, reliability, extensibility, etc) as well as positive and negative test scenarios.
接受标准 —定义新的系统功能，通常以可独立测试的系统行为的项目符号列表的形式给出。 这些包括功能和非功能需求(性能，可靠性，可扩展性等)以及肯定和否定测试方案。
An Effort Estimate — Indicates the relative complexity of the user story, typically measured in story points. The estimate is used for planning purposes to understand both when the user story might be completed as well as prioritize the story against others in the product backlog.
努力量估算值 -表示用户故事的相对复杂度，通常以故事点数衡量。 该估计用于计划目的，以了解何时可以完成用户故事，以及相对于产品积压订单中的其他故事优先考虑故事。
So how does one write a good user story? To demonstrate this, let’s walk through an example of turning a poorly written user story into something any development team will love.
那么，一个人如何写一个好的用户故事呢？ 为了证明这一点，让我们看一个示例，将写得不好的用户故事变成任何开发团队都会喜欢的东西。
This user story leaves a lot to be desired, specifically:
这个用户故事还有很多不足之处，特别是：
The description offers little information regarding what (specifically) is being worked on, who is asking for this, and why we’re working on it now.
该描述几乎没有提供有关正在 (具体)在做什么 ， 谁在要求它以及我们现在为什么在工作的信息。
No acceptance criteria are listed, making it very vague as to what the developer should actually do and how the story will be considered done.
没有验收标准列出，使得至于什么开发商应实际做和怎样的故事将被认为做了非常模糊。
No estimate is provided, making it nearly impossible to understand the effort requirement, prioritize it against other user stories, identify opportunities for phased/iterative development, etc.
没有提供估计 ，这使得几乎不可能理解工作量需求，将其与其他用户案例相对比，确定分阶段/迭代开发的机会等。
In 5 easy steps this user story can be turned into a kick-ass story the development team will love. Let’s check out how using a cheesy acronym, DARES:
通过5个简单的步骤，该用户故事可以转变为开发团队喜欢的故事。 让我们看看如何使用俗气的缩写DARES：
D — Description
D —说明
A — Acceptance Criteria
A —验收标准
R — Refinement
R —优化
E — Estimate
E —估计
S — Split
S-拆分
Let’s start by fixing the story’s title, which tells everyone what this user story is about. It’s how it’ll be referred to every day in the daily scrum and how other teams, leadership, etc. will understand the work being done from an outsider’s perspective.
让我们从修复故事的标题开始，该标题告诉每个用户故事的内容。 这是每天在Scrum中被引用的方式，以及其他团队，领导等如何从局外人的角度理解正在完成的工作。
Note: Some teams copy the description into the title (i.e. — as a…I want…so that…). Don’t do this — it makes it difficult to read the team’s backlog and can be confusing to those outside of the team.
注意：有些团队将描述复制到标题中(即- 作为……我想要……这样…… )。 不要这样做-很难阅读团队的积压，并且可能使团队之外的人感到困惑。
Let’s check out a rewrite of my crappy user story’s title:
让我们检查一下我糟糕的用户故事标题的重写：
The new title makes it clear what is being worked on (adding additional password strength requirements) and why (existing requirements pose security risks). It doesn’t explain exactly what will be developed, but gives a good-enough indication of what’s going on to those unfamiliar with the topic.
新标题清楚说明了正在处理什么( 添加了额外的密码强度要求 )以及原因( 现有要求带来了安全风险 )。 它没有确切解释将要开发的内容，但是可以很好地说明不熟悉该主题的人员所发生的情况。
Next, let’s work on the description. User story descriptions should clearly indicate who the new functionality is intended to serve, what the new functionality is, and why it’s important to the target user.
接下来，让我们进行描述。 用户故事描述应当清楚地表明谁是新功能旨在服务，新功能是什么 ，以及为什么它的目标用户非常重要的。
The most popular format for writing the description is as follows:
编写说明的最流行格式如下：
As a <user persona>…I want <some new functionality>…So that <some value is achieved>.
作为< 用户角色 > ...我想要< 一些新功能 > ...以便<获得 一些价值 >。
Occasionally user stories don’t fit into this format very easily. This most commonly happens for small, incremental changes that build upon a prior story. When this happens, try the “improve user story” format, where the who and why are assumed to be identical to the user story it’s building upon:
有时，用户故事不太容易采用这种格式。 这最常见的情况是基于先前故事的小规模增量更改。 发生这种情况时，请尝试“改善用户故事”格式，其中假设“ 谁”和“ 为什么”与它所基于的用户故事相同：
We have <some system functionality>.We want to have <some different system functionality>.
我们有< 一些系统功能 >。我们想拥有< 一些不同的系统功能 >。
If neither of the formats above fit your user story, try writing it in simple, every-day language. The description’s format doesn’t really doesn’t matter too much as long as it contains the who, what, and why.
如果以上两种格式都不适合您的用户情况，请尝试使用简单的日常语言编写。 描述的格式并不重要，只要它包含了谁 ， 什么以及为什么 。
Let’s check out my user story after adding a good description:
在添加良好的描述之后，让我们看看我的用户故事：
With this description, we now know who the user story is being developed for (Medium account holders), what will be developed (more strict password strength requirements), and why this functionality matters to them (to reduce the likelihood of their account being hacked).
有了这个说明，我们现在知道谁是用户故事正在为( 中账户持有人 )， 究竟会发展( 更严格的密码强度要求 )开发的， 为什么这个功能对他们很重要( 以减少他们的帐户的可能性被黑客攻击 )。
Acceptance criteria tell the development team what (specifically) needs to be built. Without acceptance criteria, the team can waste time building the wrong thing.
验收标准告诉开发团队有什么 (特别)需要被建立。 没有接受标准，团队可能会浪费时间来构建错误的事物。
Good acceptance criteria outline both functional and non-functional requirements (performance, reliability, extensibility, etc.) and contain positive and negative test scenarios that must be captured in order for the user story to be considered done. The more detailed the acceptance criteria, the easier it will be to estimate accurately and more confidently the development team can forge ahead knowing they’re building the right thing, so invest the time in writing them!
良好的接受标准概述了功能性和非功能性需求(性能，可靠性，可扩展性等)，并且包含必须捕获的正面和负面测试方案，才能考虑完成用户案例。 接受标准越详细，准确地估计就越容易，开发团队就知道他们正在构建正确的东西，就可以更加自信地进取，因此花时间来编写它们！
Let’s check out my user story after adding some acceptance criteria:
在添加一些接受条件之后，让我们检查一下我的用户故事：
Talk to the development team! Hold Backlog Refinement ceremonies at least once per week and create a forum for them to ask questions, express concerns, and provide feedback. Refine the acceptance criteria until everyone agrees on what (specifically) needs to be built.
与开发团队交谈！ 每周至少举行一次积压细化典礼，并创建一个论坛，供他们提问，表达疑虑并提供反馈。 细化验收标准，直到每个人都对什么 (特别)需要建立一致。
Let’s check out my user story after refining the acceptance criteria:
在完善接受条件之后，让我们检查一下我的用户故事：
Good estimates enable efficient prioritization against other stories in the product backlog and can encourage discussion around how to effectively split the user story to deliver the necessary value now while deferring other, lower priority requirements for future iterations. The goal is to quickly arrive at a good-enough estimate that reasonably reflects the complexity of the user story.
良好的估算可以针对产品积压中的其他故事进行有效的优先排序，并且可以鼓励围绕如何有效拆分用户故事以现在就提供必要的价值，同时推迟其他较低优先级要求以进行未来迭代的讨论。 目标是快速得出一个合理的估计，以合理反映用户故事的复杂性。
Let’s check out our user story after estimation:
让我们在估算后查看我们的用户故事：
Splitting user stories enables product owners to weigh the relative value of them against one another to optimize value delivery through iterative or phased development. Smaller user stories are also easier to estimate and tend to move through the software development lifecycle more quickly. When splitting user stories, be sure each resultant story still follows the INVEST principle.
分割用户故事使产品所有者可以权衡它们的相对价值，以通过迭代或分阶段开发来优化价值交付。 较小的用户故事也更容易估计，并且倾向于更快地遍历软件开发生命周期。 拆分用户故事时，请确保每个结果故事仍遵循INVEST原则。
Let’s check out my user story after splitting it into 4 smaller stories:
在将它分成4个较小的故事后，让我们检查一下用户故事：
With the user story now split the team is able to weigh the relative value of the resulting stories against one another and those in the product backlog to prioritize the most important work first while deferring others to later sprints.
现在，随着用户故事的拆分，团队可以权衡所产生故事的相对价值和产品待办事项中的相对价值，以便首先确定最重要的工作的优先级，同时将其他工作推迟到以后的冲刺中。
Writing good user stories isn’t hard, but it requires a commitment to the time needed for thorough research, documentation, discussions, and iteration on requirements to get them right. Investing in this process, however, will reap many rewards and reduce the amount of rework required when the wrong thing is implemented.
编写好的用户故事并不难，但需要投入大量时间进行彻底的研究，文档，讨论以及对需求进行迭代以使其正确。 但是，在此过程中进行投资将获得许多回报，并减少了实施错误操作时所需的返工量。
Try this technique out during your next Backlog Refinement or Sprint Planning ceremony and let me know what you think — I’d love to hear your experiences (good or bad) in the responses!
在您的下一个待办事项优化或Sprint计划典礼上尝试该技术，让我知道您的想法-我很想听听您在响应中的经历(好坏)！
翻译自: https://medium.com/swlh/writing-kick-ass-user-stories-f58641d49cb1
编写用户故事模板
