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秒等。
