Richard Lawrence 介绍了拆分用户故事的流程，包含三个部分：判断故事是否需要拆分、应用多种模式拆分故事、评估拆分效果。具体的流程见图：
http://agileforall.com/wp-content/uploads/2015/01/Story-Splitting-Flowchart-CN.pdf
我们知道一个Sprint是两周的时间，如果一个Story太大，就无法达到上述要求。那么问题来了，如何拆分它呢？
| SPIDR | 理解 |
|---|---|
| Spikes | Research，前期研究，比如要研究会用到的新技术 |
| Paths | 比如，一个需求包含不同种方式，比如添加Contact功能，可以从Portal，API，Upload三种方式，那么就可以分成3个Story |
| Interfaces | 比如一个需求同时支持安卓，IOS，PC端 |
| Data | 比如我们系统有这样的需求：在危急事件发生时，需要通知事件发生区域周围的人，但是这些人的位置信息，包括固定地点信息，如在这个区域居住或办公的，还有动态位置信息，如在这个地方出差的，或者偶然进入这个区域的，这些位置信息数据来源不同，我们可以按这个划分，逐步完善。 |
| Rules | 比如，用户想要看到不同来源的Contact数量的统计报告，但是系统统计所有Contact数量会很慢，但是一定数量的Contact比较快，这是我们可以先将规则定位比如30000条来进行统计，然后在其他的Story中性能优化，可以再改变这个规则 |
总之，在拆分Story时，SPIDR是个很好的技巧。但是，实践当中不用把这些方法都用上，只要能把Story分的小到易于完成就可以了。
拆分故事的INVEST原则
极限编程（XP）倡导者Bill Wake描述用户故事有如下6个属性，简称INVEST原则，可以作为我们拟定用户故事的现实参考。
1、独立的(Independent)
独立性和传统软件工程的松耦合的概念有异曲同工之妙。强调用户故事与用户故事之间不要有太多的依赖，因为有依赖的不同故事，可能优先级是不同，这就会给故事的工作量估计，以及故事在开发迭代的排期造成困扰。
2、可协商的（Negotiable）
故事是可以协商，故事卡是用户功能的简单描述，细节需要在客户与开发团队的讨论中产生。
3、有价值的（Valuable）
故事是以客户或用户的视角来书写，通常是业务语言而非技术语言。在故事中自然体现这个功能具体给用户带来的价值是什么。
4、可估算的（Estimate）
每个故事都对应估计的故事点数，即工作量应该是可以度量的。开发人员可以根据所业务领域的知识和相关技术经验来估计每个用户故事可能对应的故事点数。基于每个用户故事的故事点数的估算，确保纳入每次迭代的故事的总故事点数不会超过开发团队的速率，即处理能力。
5、小的（Small）
每个故事可以小到在一次开发迭代中就可以完成。合适的故事大小最终取决于团队的速率，以及所使用的技术。我们可以考虑把一些大的史诗故事通过某些规则分解为更小的可在一个迭代中就可以完成的小的故事。
6、可测量的（Testable）
故事必须是可测量的，这个和每个故事必须对应验收条件是息息相关的。可度量的验收指标是不可少的，比如系统的可用性为99.99%，99%的情况下，打开一个页面的时间不能超过2秒等。
