这是Product Monk产品管理教程的的第七章。全部章节目录参见本文。

目前为止，你已经了解了用户在不同阶段所面临的挑战，及其可能的解决方案。用户故事（user story）可以帮助我们在团队之间，高效沟通功能的详细描述。用户故事有助于让每个人都保持在同一基础上。

用户故事是从用户或客户的角度，对所讲述功能的简短描述。他们通常遵循一个简单的模板：

作为一个<用户类型>，我想要<一些目标>，(如果可以的话)这样<一些原因>。比如“作为一个消费者，我希望可以在网上买到化妆品，这样我没空出门的时候也可以即时补给化妆品了。”用户故事可以帮助你将功能需求传达给工程团队。这样，工程团队就更容易理解：他们为什么要构建这个功能，它将如何给用户带来好处，或者用户将如何使用它。

如何编写用户故事?

你应该写一个史诗般的用户故事，然后把它分解。

这个史诗（Epic）是指非常大、而且抽象的用户故事，它源自用户画像和用户旅程映射。它告诉产品应该为用户做什么(对应用户画像/客户旅程映射中，提供的用户目标)。它可以让你在不提交细节的情况下，勾画产品功能。这对于描述新产品和新功能特别有帮助：它让你捕获大致范围，并为了解如何最好地满足用户需求，争取了时间。

一旦这个史诗准备好了，就可以把它分解成更小、更详细的故事，直到它们都具备三点：清晰、可行、可测试。例如，某个功能描述为：“我想和朋友分享我的照片”。这可以被分解成——我想和朋友在Facebook、Twitter、Insta、WhatsApp分享我的照片，等等。这些都形成了不同的用户故事。

让我们看一下在第4章(用户旅程映射部分)使用的例子——用户预订酒店。让我们来看看在发现阶段的一个史诗叙述：作为用户，我希望在一个带有适当过滤器和信息的地图上，看到酒店搜索的结果。以上叙述可以进一步分解成更小的用户故事：

“作为用户，我应该能够在地图上查看结果，这样我就不必在结果列表视图和地图位置之间来回切换了。”
“当我移动地图查看其他区域时，结果应该根据新位置得到更新”
“作为用户，我应该能够在地图视图中查看我需要的信息(价格、评分、星级、照片)”
“作为用户，我应该能够在地图视图中应用过滤器(价格，评级)”

以打车服务的旅程映射为例，我们可以写下以下史诗，并进一步分解为更小的用户故事。

用户故事的验收标准

创建了用户故事之后，要为用户故事添加验收标准。验收标准是为了将故事标记为已完成，必须满足的条件。验收标准对用户故事做了完善，使其可测试，并确保用户故事可以向用户和其他利益相关者，进行演示或发布。

考虑下前面例子中，第一个用户故事：

“作为用户，我应该能够使用我的位置，这样可以看到我附近可用的出租车”。

验收标准可以是：

app应该能够检测我的位置，并在地图上指出来。
app应该能够接收任何位置的文本输入，并在地图上指出来。
一旦确定位置，附近可用的出租车应显示在地图上。

评估用户故事的标准就是：I.N.V.E.S.T.

独立（Independent）：用户故事应该是独立的，因为任何依赖都会使它们之间的优先级难以区分
可协商（Negotiable）：实现细节没有指定，它们由团队来决定
有价值（Valuable）：用户故事对客户应该是有价值的
可评估（Estimable）：它们应该被分解成团队可以开展工作的最简单形式
小（Small）：它们应该足够小，可以在一个冲刺（Sprint）内完成
可测试（Testable）：可以根据指定的验收标准，对这个增量交付进行测试

在哪里编写这些用户故事?

你可以使用类似Google表单这样的简单解决方案，也可以使用如Trello、Jira、Aha、Craft以及许多其他工具的高级方案。

用户故事评估

工作量评估是很困难的。因为传统软件开发团队以时间(小时或天)来提供估算。然而，许多团队(遵循敏捷开发实践)使用基于评估的故事点数进行估算。

故事点数（Story points）就像一种货币，它告诉你开发一个用户故事，需要付出相当于多少的努力。故事点数使用斐波那契数列格式，对工作的相对工作量进行排序，格式为： 0、0.5、1、2、3、5、8、13、20、40、100。这种抽象可以帮助团队用更少的工作量对工作的难度，做出艰难的决定。下面的矩阵(由Dan Olsen编写)有助于指导如何将故事点数分配给用户故事。

简单来说，你也可以根据以下定义来分配故事点数：

1个点数——我非常清楚需要做什么，也非常清楚如何去做。
2个点数——我非常清楚需要做什么，但我需要做一些研究或实验，弄清楚如何去做。
3个点数——我大部分了解需要做什么，对于如何去做也了解一些。(但完全否定这个故事，是大概率不会的)
如果用户故事拥有的故事点数高于5点或8点，那么它们通常被分解成更小的用户故事。

规划扑克（Planning Poker）评估技术

在这种方法中，团队成员拿到的卡片上，写有基于斐波那契数列的数字。协调人(通常是产品经理/负责人)提供用户故事的简短介绍，团队成员将展示用户故事的卡片。评估点数的任何差异都要被讨论。通常，在对评估点数的最低值和最高值进行一两轮讨论之后，团队会达成一致意见。

下一章，我们将看看如何验证你的MVP。

推荐阅读：