如何对一个产品编写完整的用户故事?

Posted 2023-04-01 PingCode丨智能化研发管理工具

用户故事是敏捷项目管理的核心实践之一，除了定义、表达“公式”，本文将给大家分享用户故事的价值，比如用户故事在非技术的角度告知研发团队需求背景是什么，让研发团队更轻松的了解用户需求场景、目的、功能预期和实现价值。

用户故事从终端用户的角度概述他们想要实现的功能，其目的是为了阐明这个功能要给客户提供的价值。

我们很容易把用户故事简单地认为是软件需求，但它并不等同于软件需求。 敏捷开发的一个核心理念是以人为本，而用户故事正是以用户为中心的。用户故事站在非技术的角度告知研发团队需求背景是什么，让研发团队更轻松的了解用户需求场景、目的、功能预期和实现价值。

用户故事是敏捷项目管理的核心实践之一，它可以帮助研发团队在日常工作中培养以用户为中心的意识，提高团队协作性和创造性，从而打造出更好的产品。

一、什么是敏捷用户故事

用户故事是敏捷开发中最小的工作单元，它代指的不仅仅是一个功能，而是从用户角度阐述的一个产品目标。它站在用户的角度以通俗易懂的方式描述了软件功能。

用户故事的目的是阐明一个软件功能要传达给客户的特定价值。需要注意的是，“客户”不一定是外部用户，他们还可以是公司内部员工。

在经过团队评审达成一致之前，用户故事通常是简单的几句话，概述了用户需求的预期结果。一旦研发团队把用户故事加入排期之后，就会补充该用户故事相关的需求。

用户故事非常适合敏捷方法，比如 Scrum 和 Kanban 。在 Scrum 敏捷项目中，用户故事会被添加到迭代（Sprint）中，并在迭代中实现。而在 Kanban 中，用户故事会被放入看板的待办栏中，并随着 Kanban 团队工作流进行流动、完成。

用户故事的工作模式可以帮助 Scrum 团队更好地进行工作量评估并完成迭代计划，提高团队目标预估的准确性和团队工作的敏捷度。而在 kanban 模式下，则可以帮助团队了解怎样管理在制品，并进一步完善工作流程。

用户故事也是更大的敏捷框架（史诗和特性）的组成单元。特性是由多个用户故事组成的功能模块，而多个特性构成了史诗。这些更大的框架有助于确保研发团日常工作是朝着正常的目标前进。

​

二、用户故事能带来哪些优势

对于刚接触敏捷的开发团队来说，用户故事有时似乎是一个额外的步骤：为什么不直接将项目级工作（史诗）分解为一系列步骤来执行呢？这是因为用户故事可以为团队提供了重要的背景，并将任务与这些任务带来的价值联系起来。

用户故事具有许多优势：

1. 用户故事以用户为中心：待办任务列表让团队专注于需要完成的任务，但用户故事可以让团队专注于用户真正想解决的问题；

2. 用户故事促进团队协作：定义最终目标后，团队可以共同决定如何最好地为用户提供服务并实现该目标；

3. 用户故事让解决方案更具创新性：用户故事鼓励团队批判性和创造性地思考如何最好地实现最终目标。

4. 用户故事让团队更有动力： 每完成一个用户故事，开发团队都会享受到攻克一个小挑战带来的胜利，从而更有动力。

三、如何使用用户故事

用户故事一般由产品负责人（Product Owner）、产品经理或项目经理撰写和审核，撰写完成后将进入团队的研发流程当中。

在迭代前期或迭代计划会议期间，团队要确定本次迭代要完成哪些用户故事，并讨论每个用户故事场景下的需求和功能。团队在为每个用户故事构建解决方案过程中将激发成员的创意以及学习到其他技术。当研发团队对用户故事的实现方案达成一致，就会在用户故事中补充功能实现相关的需求描述。

迭代计划会议的另一个常见事项是根据用户故事的复杂度或完成时间进行工作量评估。研发团队一般使用 T 恤尺寸、斐波那契数列或规划扑克牌的方法来估算合适的故事点。用户故事应该被分解成能在一个迭代中完成的大小，因此当团队估算每个故事时，他们要确保分解将超过该完成范围的故事。

四、如何编写用户故事

在编写用户故事时需要考虑以下几点：

• “完成”的定义——当概述完一个用户故事后，一定要定义其完成的标准是什么。

• 概述子任务或任务——确定需要完成哪些特定步骤以及每个步骤的负责人。

• 用户角色——用户是谁？如果有多个用户，则需要考虑编写多个用户故事。

• 有序步骤——给大规模流程的每一个步骤写用户故事。

• 倾听用户声音——与您的用户交谈并从他们的角度来描述问题和需求。当能够从客户那里获取用户故事时，就不用猜测客户需求了。

• 时间——时间是一个敏感的话题。许多研发团队在评估时会忽略用户故事的实际完成时间，只依靠过往的估算经验来评估。用户故事应当在一个迭代中完成，因此应该把那些数周或数月才能完成的用户故事拆分成更小的用户故事，或者应该把它们上升为特性层级。

一旦明确定义了用户故事，请确保团队所有人都能看到它们的进度。

五、用户故事模板和示例

用户故事通常用一个简单的句子来表达，结构如下：

“作为一个[XX角色]，我[想要什么]，[以便达到什么目的]。”

结构分解如下：

• “作为[XX角色]”：我们是为谁实现这个需求？我们不仅要知道用户的职称，还要了解用户角色的特点。研发团队应该对用户角色有一个共同的理解。团队应该尽可能多地采访目标用户，了解他们的工作方式、想法和使用感受，对用户要有同理心。

• “想要什么”：这里我们描述的是用户的意图——而不是他们想使用的功能。用户本质上想达到什么目的？这个描述不用体现功能的实现——如果你描述的是软件功能而不是用户目标，就没有抓住重点了。

• “以便达到什么目的”：用户期望做的这件事符合他们的规划吗？他们想实现的整体效果是什么？需要解决的本质问题是什么？

例如，用户故事的结构可以参考下方：

• 作为小凯，我想邀请我的朋友，以便一起体验这项服务。

• 作为老王，我想整理我的所有工作，以便我对工作更有掌控感。

• 作为项目经理，我希望能够了解项目成员的工作进展，以便更好地汇报我们的成果和不足。

这些表达不是固定的，但是有助于定义用户故事的完成标准。当用户可以精准表达他想要实现的价值时，一个用户故事就诞生了。我们鼓励研发团队根据自身情况规范用户故事的表达结构并在工作中坚持实践。

六、敏捷用户故事入门

用户故事解释了开发团队成员日常工作的目的和内容，表达结构通常为“角色 + 需求 + 目的”。让团队了解他们交付内容的来源用户及其真实目的，可以很大程度上促进研发流程的进展。

可以从下次评估大规模的特性项目（Feature）开始，尝试把特性拆分为一个个具体的用户故事，由研发团队共同协作优化。当把用户故事同步给团队所有成员后，研发团队就可以开始工作了。

这里推荐使用 PingCode 研发管理工具，内置标准的用户故事工作模板，更支持特性、史诗、缺陷、任务等各种工作类型，帮助您的团队快速开启敏捷研发。

延伸阅读：

Scrum 开发指南： Scrum 框架详解  |  Scrum 四个会议及正确召开方式 |  正确的计划和执行Sprint的方式 |  做好迭代计划的4大关键点 |  做好这4点让每日站会更适配敏捷团队  |  开好迭代评审会的3个关键步骤  |  为什么要召开迭代回顾会  | Scrum 3大角色及其岗位的具体职责  |  Scrum三大工件在敏捷开发中的作用  |  2022年14个最佳 Scrum 敏捷项目管理软件  |  更多 

Kanban 敏捷指南： 使用看板（Kanban）管理方法的5大好处  |  看板 VS Scrum：如何选择？ |  看板和 Scrum 的混合模式适合在哪些场景使用  |  更多 

规模化敏捷： 规模化敏捷的价值及五大规模化敏捷框架  |  规模化敏捷之 Spotify 模型  |  规模化敏捷框架之LeSS框架  |  SAFe 规模化敏捷框架  |  Scrum@Scale 模型  |  敏捷项目组合管理  |  OKR与敏捷开发  | 更多 

 

简洁的用户故事编写格式

对于多数产品待办事项列表（product backlog）项，尤其是产品功能类，敏捷团队通常使用用户故事（user story）来表达预期的商业价值。

 

用户故事（user story）的格式通常如下：

 

简洁的格式可以帮助团队完成较好的用户故事（user story）：容易让业务和技术人员准确理解。然而，有时候团队分配给用户角色的目标和利益，并不符合用户角色真实期望的需求和愿望。乍一看，这些用户故事（user story）写的很好，当从特定用户角色的角度去看时，发现并不正确。 我自己的一个例子。几年前，我带领的一个用户故事（user story）写作研讨会，主题是为某公司建立一个电子邮件系统。这个系统比较特别，它将会被大型电信运营商（如 AT&T和Verizon）授权使用。当时的想法是，当人们从AT&T和Verizon购买一部手机时，他们会从运营商那获得一个免费的邮箱帐户。

研讨会上，一个团队创建的用户故事（user story）如下：

 

当我看到这个用户故事（user story）时，我的第一感受是，“作为一名手机用户，我不希望在我的邮件信息中看到任何广告。” 这个团队感到困惑。“你是怎么理解的？”，他们问，“这个用户故事（user story）的核心是—我们必须把广告放进电子邮件中，才能让运营商为用户提供免费的电子邮件帐户” 我回答说，“我知道。但是，这样的用户故事（user story）是行不通的，因为从手机用户角度来说，它毫无意义。”

 

我写了一个新的卡片给了那个团队，“这样的用户故事（user story），才能真正准确地反应手机用户的想法”，如下：

 

 

在每个人读过卡片之后，我补充道“你之前写的用户故事（user story）从用户角度来看是没有意义的！手机用户不希望广告出现在他们的邮件中（谁也不希望广告出现在他们的邮件中！）。这样的用户故事（user story）是不合常理的。” 然后我建议他们从手机用户的角度重写一个真正对用户有价值的用户故事（user story）。

 

这个故事大体如下：

现在这个故事才是有意义的！用户故事（user story）中的用户角色必须是能真正得到这个故事中所描述的价值的角色。这样的角色才符合要求。 当你在写用户故事（user story）时，请停下来仔细考虑一下使用你描述的具体功能的用户角色是谁。是你的客户还是你的客户的客户？公司开发的邮件系统的客户是电信运营商（AT&T 和 Verizon）。他们客户的客户是手机用户。两者都有可能是用户角色，所以需要故事能反映正确的用户角色的需求。 如果你的待办事项列表中存在目标和角色不匹配的故事，可能你需要重写这些用户故事（user story）了。

【本文由“软动力”发布，2017年06月04日】