在开发过程中，产品经理需要培养和维护与许多人的关系. 然而，其中最亲密的将是产品用户. 你应该彻底了解他们:他们是谁，他们的喜好，他们的需求. 发展和维持这种关系的一种方法是写作 用户故事.

就像宣言和愿景文档一样，用户故事是一个不可分割的部分 产品开发. 好的用户故事是推动高效规划和交付的关键, 团队参与, 以及客户满意度. 模糊的用户故事通常表明团队将努力完成进一步的任务-这是我作为一名工程师经常目睹的 产品经理.

我参与过一些成功的初创公司，也有一些失败了，这让我亲身体会到花时间构思高质量用户故事的重要性. 本指南将帮助您和您的团队掌握每个元素，并一次又一次地编写高质量的用户故事.

什么是用户故事?

用户故事是产品的一个小增量，表示它将为最终用户提供的价值. 一组用户描述 创造史诗，一个产品可以包含多个史诗. 用户故事可以进一步分解为更准确地反映工作和概述如何完成故事的任务. 用户故事通常采用这样的公式:用户-功能-效益, 哪些可以有效地应用于大多数行业和企业.

通常, 产品经理 负责编写用户故事，但有时这可能落在 产品负责人、Scrum管理员或工程经理. 理想情况下，每个用户描述都将由承担这项工作的一个或几个人进行审查.

一个好的用户故事有什么好处?

一个好的用户故事有几个好处 团队与产品:

• 定义“谁”并从用户的角度进行写作，可以确保将重点放在客户身上, 而不是团队想要什么或更喜欢什么.
• 定义“是什么”澄清了完成任务的人的标准，也就是所谓的执行者. 任何不在故事中的内容都可以被认为超出了范围.
• 定义“为什么”可以激励执行者，帮助他们理解交付成果对用户生活的影响.
• 定义用户价值可以帮助在开始工作之前识别不太有益的特性，从而潜在地浪费资源.

一个好的用户故事是什么样的?

If, 例如, 你正在为你的客户建造一所房子, 你的其中一个故事是关于创造围墙的. 一个糟糕的用户故事可能会说“我需要墙”——确定“什么”，但仅此而已. 更好的说法是:“作为房主, 我希望我的房子有围墙，不让外界的元素进来, 这样屋顶就不会掉下来砸到我头上.“我相信, 虽然, 如果一个用户故事真的实现了它的目的, 它应该清楚而简洁地回答以下所有问题:

• 用户是谁??
• 用户想要什么? 用户为什么需要这个?
• 工程团队应该如何解释这个故事?
• 这个故事是否依赖于另一个已经完成的故事?
• 这个描述的完成是否启用了待办事项列表中的另一个描述?
• 范围是什么.e.，最低标准是什么??
• 这个故事有多大.e.，它在估计尺度上落在哪里)?

这是我使用的模板——它随着我的 产品管理知识 多年来一直对我很有效

一个常见的用户故事神话

在判断用户故事是好是坏的时候, 我想消除一个普遍存在的误解.

许多人认为用户故事应该在一个 单一的冲刺如果不是，那就是一个糟糕的用户故事. 事实并非如此. 当然, 最好是在sprint中完成用户描述(这应该是可以实现的)。, 但是团队的带宽和外部因素可能会影响可以完成的工作量——这在每个sprint之间都是不同的. 也, estimates generally assume that every development team member has the same skill level across all domains; the fact is, 经验丰富的工程师比初级工程师完成任务所需的时间要少.

You shouldn’t try to craft short 用户故事 just so that they will be completed quickly; rather, 您的用户描述应该设法表示交付的价值的逻辑增量. 不要让时间表左右你创造引人注目的用户故事.

把用户放在最前面和最中心的位置

我发现，当我对自己的能力有信心时，项目是最愉快、最成功的 用户的知识你可以在我的网站上了解更多关于我的经历 个人博客. 无论我是在推销新功能还是与我的团队决定交付范围, 知道用户会说什么是测试我的视觉的最可靠的方法. 它是, 然而, 如果我不经常想到他们，就很容易失去与用户的联系，因此也就失去了“为什么”. 对于大多数产品经理来说，这是事实，他们的注意力经常被拉到其他任务和职责上. 编写好的用户故事可以帮助您和您的团队成员在您的脑海中保持用户的形象, 甚至增进你和他们的关系.