人们总是喜欢做一些“大”事，想彰显自己的能力，我承认做有意义和愿景的大事是每个人必须追求的。

在我们的敏捷团队中，我们经常看到团队编写大的用户故事，基于大的用户故事估算，大家认为这样会对用户故事进行快速的估算，能够减少团队会议的时间，倾向于 线下各自浏览需求，而不是团队一起审阅需求。大的用户故事真的高效么？

我们从为什么我们需要小的用户故事说起：

聚焦（Focus）

- 小的用户故事帮助我们聚焦在近期交付的用户故事上，大的用户故事拆分成小故事后，将小故事重新进行优先级排序，我们关注在有价值，优先级高的小故事上。

- 小的用户故事可以提高团队的满意度。

- 人们在成功完成一些小事情后，身体可以分解多巴胺。

透明（Transparency）

- 在我们的 “每日站会”中，小的用户故事可以可视化我们sprint的进度。

- 我们的团队进度可以很容易跟踪，每个小故事是否完成，还剩余多少。

- 产品干系人可以很容易的了解项目进度。

可预测（Predictability）

- 小的用户故事估算更趋向于真实的实际工作量，和真实的团队速率（velocity），这些都减少了估算的变异性（variability）和预测（Predictability）

- 用户故事点估算使用斐波那契数列（Fibonacci），原因之一就是斐波那契数列 越是靠后的数字越大，这样团队不得不将用户故事拆小。如果是20-30点的用户故事肯定没有2-5点的用户故事估算准确。

灵活性 (Flexibility)

- 团队在持续不断的对用户故事进行拆分时，我们会不断学习用户需求，纠正对用户故事的理解。伴随着我们的学习，团队将更适宜这种灵活性

- 当业务变更发生或用户故事优先级调整时，对小故事进行改造或移除就会减少浪费和节省时间。

吞吐量 (Throughput)

从测试左移的实践来看

- 更小的用户故事能够帮助测试人员在sprint开始阶段更快的介入测试（自动化测试等）。

- 因为用户故事小，团队聚焦在少量代码的质量，更优质代码的集成。

减少风险(Reduced Risk)

- 大的用户故事增加了团队在sprint结束时没有交付任何100%完成的故事的风险。

- 团队能力就像一个漏斗，当我们强制将一个大的用户故事塞给一个研发人员，就像漏斗一样被堵塞住。例如，开发一个大型用户故事的开发人员也可能是唯一拥有完成另一个关键故事的技能的人。

怎样才能拆分到更小的用户故事？

网络上有很多这类文章，可以很容易找到。

这里我更多是提出一些思考？

- 如果一个用户故事可以包含了多个价值结果，那它们都是优先级最高的么？ 都是用户关心的么？

- 是否可以根据 80/20 原则将用户故事拆分，是否将拆分后的小用户故事重新进行价值排序？ 我们-- - 是否先只专注20% 的用户故事？

- 是否有多个业务规则和用户画像在一个用户故事中？

- 不同的业务规则可以创建不同的用户故事；

- 不同的用户画像可以创建不同的用户故事

- 是否在不考虑异常路径的情况下，先把 “快乐路径（Happy Path）”开发？？  异常路径出现的可能性，异常路径的用户故事是否拆分，排序？

- 通常地增删改查（CRUD），我们是否实现基础功能，满足20/80原则？  是否能够一次性在一个sprint 中开发完？

- 我们设计哪些测试场景？是否有一些测试场景很复杂，并且不是频繁遇到的？

- 是否有一些复杂的用户故事和非功能性需求（non-functional requirements ）有关？ 比如安全测试，性能测试。是否我们可以将这些从当前的功能用户故事中拆分出来，成立独立的用户故事？

多小才“小”？合适的大小？

这是一个非常主观的问题，它取决于几个因素，包括团队能力、sprint长度和其他方面。我们建议使用 I.N.V.E.S.T 原则来设计用户故事。

每个用户故事都应该有价值，每一个Sprint中我们都期望给客户交付更高的价值。我们不是为了小的用户故事而去拆分，而没有任何价值意义。最重要的是较小的用户故事比较大的用户故事更好。团队在拆分用户故事的时，能够充分的交流和沟通，将验收标准（acceptance criteria）协商并统一。