编写用户故事模板_编写踢屁股用户故事

编写用户故事模板

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流程的基本部分：

什么是用户故事？ (What are User Stories?)

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?

  价值增量 —完成后，用户故事应最终通过以某种方式增强用户体验来创造业务价值。 如果它不这样做，那为什么要继续做呢？

谁撰写用户故事？ (Who Writes User Stories?)

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.

任何人都可以编写它们-伟大的想法可以来自任何地方，并且通常来自与工作最接近的人。 虽然产品所有者是最终为了什么开发团队的作品上， 当负责， 人人负责确保只有良好的用户故事使之成为一个冲刺，不管是谁最初写的。

用户故事中有什么&#