作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
在开发过程中,产品经理需要培养和维护与许多人的关系. 然而,其中最亲密的将是产品用户. 你应该彻底了解他们:他们是谁,他们的喜好,他们的需求. 发展和维持这种关系的一种方法是写作 用户故事.
就像宣言和愿景文档一样,用户故事是一个不可分割的部分 产品开发. 好的用户故事是推动高效规划和交付的关键, 团队参与, 以及客户满意度. 模糊的用户故事通常表明团队将努力完成进一步的任务-这是我作为一名工程师经常目睹的 产品经理.
我参与过一些成功的初创公司,也有一些失败了,这让我亲身体会到花时间构思高质量用户故事的重要性. 本指南将帮助您和您的团队掌握每个元素,并一次又一次地编写高质量的用户故事.
用户故事是产品的一个小增量,表示它将为最终用户提供的价值. 一组用户描述 创造史诗,一个产品可以包含多个史诗. 用户故事可以进一步分解为更准确地反映工作和概述如何完成故事的任务. 用户故事通常采用这样的公式:用户-功能-效益, 哪些可以有效地应用于大多数行业和企业.
通常, 产品经理 负责编写用户故事,但有时这可能落在 产品负责人、Scrum管理员或工程经理. 理想情况下,每个用户描述都将由承担这项工作的一个或几个人进行审查.
一个好的用户故事有几个好处 团队与产品:
If, 例如, 你正在为你的客户建造一所房子, 你的其中一个故事是关于创造围墙的. 一个糟糕的用户故事可能会说“我需要墙”——确定“什么”,但仅此而已. 更好的说法是:“作为房主, 我希望我的房子有围墙,不让外界的元素进来, 这样屋顶就不会掉下来砸到我头上.“我相信, 虽然, 如果一个用户故事真的实现了它的目的, 它应该清楚而简洁地回答以下所有问题:
这是我使用的模板——它随着我的 产品管理知识 多年来一直对我很有效
组件 | 问题 | 回答 | 目的 |
---|---|---|---|
用户角色 |
用户是谁?? | 用户是一个来自芝加哥的富人,他正在汉普顿建造一座豪华的避暑别墅. | 充分设想用户, 团队与许多不同的角色一起工作, 所以尽可能详细是很重要的. |
用户故事 | 用户想要什么? 用户为什么需要这个? | “作为房主, 我想在我的家周围装饰成对角线编织图案的砖墙,因为我每天都会看到它们,希望它们是一个令人愉快的景象.” | 理解用户的动机和他们的推理. |
Summary | 工程团队应该如何解释这个故事? | 用户想要精致的墙壁, 所以我们需要建立一个规则的中央墙,然后有脚手架所需的风格(i.e.(斜线编织). 我们可以用普通砖做核心墙, 但是需要使用高质量的装饰砖来装饰墙两侧的立面层. | 将故事逻辑地分解成任务,这有助于跟踪进度. |
先决条件 | 这个故事是否依赖于另一个已经完成的故事? | 为了开始研究这个, 房子的地基需要完成,准备在上面建造. | 解释故事在工作流层次结构中的位置,并可视化整个交付时间线. |
后置条件 |
这个描述的完成是否启用了待办事项列表中的另一个描述?
| 墙建好后,我们就能搭起支撑柱,最后是屋顶. | 解释故事在工作流层次结构中的位置,并可视化整个交付时间线. |
完成的定义 | 范围是什么?? | 房子周围应该有一套连续的外墙, 在墙的两侧都有对角线编织风格的立面. 墙的端到端宽度应不小于12英寸. | 定义一个故事何时完成. 解决方案需要包括这里列出的所有内容. |
t恤尺寸 | 这个故事有多大? | 媒介 |
松散地估计整个故事的交付时间. 然后,执行者将为每个任务完成更细粒度的评估.
|
在判断用户故事是好是坏的时候, 我想消除一个普遍存在的误解.
许多人认为用户故事应该在一个 单一的冲刺如果不是,那就是一个糟糕的用户故事. 事实并非如此. 当然, 最好是在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, 您的用户描述应该设法表示交付的价值的逻辑增量. 不要让时间表左右你创造引人注目的用户故事.
我发现,当我对自己的能力有信心时,项目是最愉快、最成功的 用户的知识你可以在我的网站上了解更多关于我的经历 个人博客. 无论我是在推销新功能还是与我的团队决定交付范围, 知道用户会说什么是测试我的视觉的最可靠的方法. 它是, 然而, 如果我不经常想到他们,就很容易失去与用户的联系,因此也就失去了“为什么”. 对于大多数产品经理来说,这是事实,他们的注意力经常被拉到其他任务和职责上. 编写好的用户故事可以帮助您和您的团队成员在您的脑海中保持用户的形象, 甚至增进你和他们的关系.
在编写用户故事时, 您应该包含有关用户角色的详细信息, 他们想要什么,为什么, 如何将故事分解成任务, 任何其他相关或受影响的故事, 故事的范围, 和大小.
一个好的用户故事鼓励采用以客户为中心的方法, 提供清晰的目的, 激励团队成员, 提高效率.
至少, 用户故事应该确定三个基本要素:用户是谁, 他们想要什么, 以及他们为什么想要它.
世界级的文章,每周发一次.
世界级的文章,每周发一次.