工作中遇到很多同事问到用户故事的相关概念，而且基本是每新来一个同事就要解释一遍，这里做个总结，希望以后不要再做这个重复性的工作了。😹

1. INVEST

INVEST是用户故事的书写标准，具体每个字母的含义如下：

1.1. Independent(独立的)

一个用户故事对于另一个用户故事应该是尽可能独立的。为什么呢？因为传统的需求描述方式（功能模块、用例等等）由于个体较大，彼此之间依赖较多，导致输入到开发阶段时开发工程师不太容易计划他们的工作，从而导致的开发延期的现象就变成大家习以为常了。而独立性较好的故事能够独立交付，从这一点，用户故事就充分的考虑到了需求与开发的敏捷化连接问题。

那要如何才能做到用户故事之间的独立性呢？通常，可以通过组合用户故事或者分割用户故事来减少依赖性。

1.2. Negotiable(可协商的)

大家对所有之前达成的一致在新的变化发生情况下，协商后达成新的一致，从而推动系统的研发进展。

上面是比较书面的解释，我的理解是这样的：
用户故事可协商的地方，在于验收标准（AC），同样一个手机号+验证码的注册功能，我们既可以写成如下的验收标准（以下只是举例，真实的验收标准建议参照Given-When-Then的格式编写）：

手机号是11位数字
手机号只能是13、15、17、18开头
验证码一分钟只能发送一条
发送验证码之前需要做个图片验证
验证码的有效期是5分钟
验证码4位数字
密码6-12位
密码只能是字母、数字、下划线的2种或3种的组合
……

如果按照这个验收标准来做，一个注册功能可能就要开发一周左右，但是早期我们为了快速进行后续的开发，可以暂时降低我们验收标准：

手机号是11位数字
验证码一分钟只能发送一条
验证码4位数字
密码6-12位

这样就能迅速完成注册的功能，继续后续的开发了。
这就是我理解的用户故事的“可协商的”概念。

协商去掉的这些验收标准，不是说以后都不做了，而是暂时为了完成整个MVP，就先牺牲掉了，这些细节还可以在后续的迭代里再加上。

1.3. Valuable(有价值的)

每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。

书写用户故事的三段论：

作为（XX角色），我想（XX功能），从而（实现XX价值）

最后一句话，就是在强调价值的重要性。

1.4. Estimable(可估计的)

开发者需要去估计一个用户故事以便对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

1.5. Small(短小的)

一个好的故事应该在工作量上短小，描述具有代表性，而且不超过3人天（或者3故事点）的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。

1.6. Testable(可测试的)

一个用户故事是可测试的并用来确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。

小结
一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。

2. 3C

3C是收集用户故事的有效手段，具体每个C的含义如下：

2.1. Card（卡片）

用卡片（Card）来简要描述故事。

2.2. Conversation（会话）

与Product Owner（或客户）交谈（Conversation）来明确细节。

2.3. Confirmation（确认）

验收评审，确认（Confirmation）被正确完成。

3. DEEP

DEEP原则是用来梳理Product Backlog的，改概念最早在Mike Cohn的《Succeeding with Agile》一书中提到。

3.1. Detailed Appropriately（详略得当）

接下来的1~2个Sprint中要完成的用户故事，需要足够的详细。而不着急开发的，则不必太详细。

3.2. Estimated（做过估算的）

Product Backlog中的需求都要是经过估算的，只不过靠后（优先级低）的PBI没有充分理解（也不必），因此其估算也不如靠前（优先级高）的PBI估算精确。

3.3. Emergent（涌现的）

Product Backlog不是静止的。随着了解的深入，Product Backlog中的用户故事会增加、减少、删除、拆分或重新排优先级。

3.4. Prioritized（排列优先级的）

Product Backlog应该根据由上至下按照条目的价值从高到低排序。团队应根据优先级进行开发，从而使正在开发的产品或系统价值实现最大化。

4. WSJF

规模化敏捷框架SAFe(Scaled Agile Framework)提出了一种定量计算法来评估需求的优先级，称为WSJF(Weighted Shortest Job First: 加权最短作业优先)。

计算公式如下：

WSJF

其中分母的工作规模部分大家比较熟悉，即估算的需求规模(故事点方法、理想时间方法等)。

分母部分的延期成本包括三个因子：

4.1. User and Business Value(用户和商业价值)

指的是对客户或商业的相对价值，比如：

用户更喜欢哪个?

对盈收有什么影响?

不做会产生什么潜在的负面影响?

4.2. Time Criticality(时间关键性)

指的是给用户的商业价值随着时间的推进如何变化。比如：

是否是固定交付日期类型的需求?

用户是否会愿意等待，还是会选择其他产品?

在某个时间窗口不上线的话，是否会影响用户的满意度?

4.3. Risk Reduction& Opportunity Enablement(减少风险或帮助获取新机会)

指的是除了上面的第1个和第2因子需要考虑因素之外，这个需求还能为业务带来哪些价值, 比如：

是否降低产品以后交付某些必要特性的风险?

是否会学到我们不知道的知识或信息?

是否会带来新的商业机会?

这样拆解后，WSJF的公式细化为：

WSJF公式

如何操作呢?将所有特性列成表，如下：

WSJF计算方法

对这个表中WSJF公式中的每个因子，采用与用户故事的故事点相对估算类似的方法做估算。比如，对于工作规模这一项，选择一个工作规模最小的特性作为基准，它的工作规模设为1（注意：WSJF公式中的每一项，都要选中一个特性作为相对估点的1），其他特性的工作规模与之相对比, 采用近似斐波那契数列1, 2,3, 5, 8,13, 20…为单位。如果特性A是基准特性的3倍，那么特性A的工作规模就是3。

为WSJF公式分子的其他因子做同样的相对估算法，即找到一个因子最小的基准特性，然后其他特性与之相比较，从而得到相应因子的估算数值。

就每一个特性，将WSJF的每个因子做相对估算后，就可以计算出每个特性的WSJF，这样你就得到了量化的需求排序。

常见疑惑：WSJF适用于所有需求的排序吗?

不是的。在SAFe里，WSJF可以适用于大粒度的Epic和Feature级需求，不适用于小颗粒的用户故事级需求，原因是用户故事通常很小，分母的几个因子不容易对比出差异。此外这种定量计算法在团队里应用过于沉重，因为需要对每个需求估算四个因子，不止是需求规模这一个因子，所有估算的耗时翻了四倍。

5. MoSCoW

MoSCoW法则是用来排定用户故事优先级顺序的一种定性方法。
具体这个缩写的含义是什么，具体怎么用，可以参考这篇文章：如何利用MoSCoW法则排定Sprint Backlog的优先级

6. SMART

SMART是用来将用户故事拆分为任务时的指导原则。

6.1. Specific（具体的）

任务必须是具体的。

6.2. Measurable（可以衡量的）

任务必须是可以衡量的。

6.3. Attainable（可达成的）

任务必须是可以达成的。

6.4. Relevant（相关的）

任务与最终目标是要相关的。

6.5. Time-bound（有时限的）

任务必须具有明确的截止期限。