用户故事

Scrum培训中讲到一个重要的资产就是Product Backlog（产品待办列表），它是一个动态的列表，包含可能会进入产品的工作。每个条目称为PBI，通常，用户故事（user story）作为一种常见的PBI形式。

用户故事 User Story

什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能，最早来自于1999年极限编程中的一个实践。一个好的用户故事包括三个要素：

1. 角色-Who：谁要使用这个功能。

2. 活动-What：需要完成什么样的功能。

3. 商业价值-Why：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：As a [who], I want [what] , so that [why].

中文：作为一个<角色>, 我想要<活动/方案>, 以便于<商业价值>

举例：

作为一位招聘者，我想要发布一个职位信息，以便于应聘者能够看到和投递该职位。

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

Jeff Paton升级Ron Jeffries的5C

卡片（Card） – 用户故事一般写在小的报事贴卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试用例确认用户故事被正确完成。
构建(Construction) – 团队通过技术手段实现这个用户故事的要求和功能。
后果(Consequence) – 交付给用户真正使用，并获取反馈。

优秀用户故事的六个特征- INVEST原则

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

1. 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
2. 可协商（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
3. 有价值的（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
4. 可估算的（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
5. 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
6. 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

优秀产品待办列表的八个特征- UPERFORM原则

为了让团队在迭代开始之前就能将PBI（需求待办条目）做到准备就绪（Ready），以便团队在迭代中能将其做到满足“完成的定义”（Definition of Done），我们提出一套UPERFORM原则，帮助团队和PO评估就绪程度。

• Unified, 唯一的
• Pull-based, 基于拉动式的
• Emergent, 动态涌现的
• ROI, 投入产出比
• Feature-sliced, 按特性纵切
• Ordered, 已排序
• Refining, 持续精炼
• Measurable, 可度量