根據INVEST原則，對使用者故事的要求是它必須“足夠小”或具有合適的大小。使用者故事應該足夠小，可以在衝刺中完成6-10個。當然這也取決於開發團隊的速度。為了原則上實現這一目標，必須相應地分割大型故事。在下文中，我想向您介紹Mike Cohn的簡單快速的SPIDR方法。他總結了五種技術，幾乎每個大型使用者故事都可以分為幾種。
釘鞋
Spike是敏捷軟體開發中使用的術語。尖峰是功能的小型原型實現，通常用於新技術的評估和可行性。
該方法涉及調查和建立知識。如果其他SPIDR方法效果不佳，則應該使用它。藉助這些新獲得的知識，可以更好地理解一些故事，並可能更容易地分裂。然而，該方法相對抽象，因此比其餘方法更難應用。
路徑
如果使用者故事中有多個可能的備用路徑，則一個選項是從這些路徑中的某些路徑建立單獨的使用者故事。為每條路徑寫一個故事並不是絕對必要的，只要它有意義。例如，讓我們看一個使用者想要線上商店購買的使用者故事。現在有兩種可能的途徑：使用信用卡付款或使用Paypal付款。理論上，信用卡付款可以進一步細分，但你需要權衡每種型別的信用卡是否有自己的故事。然而，支付購買的首要任務分為上述兩種備選方案。因此，新建立的故事更小，更容易估計。
介面
在該上下文中的介面可以是例如不同的裝置或裝置型別，例如由iOS或Android供電的智慧電話。使用者故事也可以根據這種多樣性進行劃分。讓我們堅持使用不同作業系統的示例：例如，在專案中，可能存在僅與Android裝置的使用相關的使用者故事，或者專注於Web瀏覽器的其他使用者故事。為了避免使故事過於龐大和全面，您應該問自己要開發哪些裝置或介面。也許第一個開發結果應該只引用iOS裝置，因為可能更大的目標組。
資料
當初始故事僅涉及相關資料的子範圍時，可以使用另一種用於分割使用者故事的技術。以一個旨在吸引遊客到特定城市的網站為例。例如，如果它是以博物館而聞名的城市，那麼第一個故事可能包括該地區不同博物館的資訊。隨後的故事可能包括穿越城市的各種旅遊，以及另一項戶外活動。
規則
業務規則或技術標準可能是另一個分裂因素。以線上購買電影票為例。通常存在約束，例如基於相應電影的業務要求，例如每個電子郵件地址最多五個票的線上購買限制。
有了這個故事，可以想象開發團隊省略了這個限制，允許每個訪客購買儘可能多的門票。然後可以在第二次迭代步驟中新增限制。像這樣的增量交付意味著初始故事不會立即完全實現，而是以幾個較小的步驟提供。有時忽略技術規範或業務規則是有意義的，如果通過這樣做，您可以更快地實現滿足使用者或客戶的可呈現結果。可以在以後檢索省略的故事。
小使用者故事 - 更容易實現
使用者故事分裂並不總是那麼容易：許多初學者傾向於將他們的故事過於全面而且過於龐大。但是，當涉及到開發團隊的改進，並最終實現故事時，很快就會發現必須製作更小的故事。在我之前關於寫（好）使用者故事的博文中，我堅持認為故事應該是“可估計的”和“小的”。如果您知道如何分割大型故事，則更有可能發生這種情況。正如編寫使用者故事一樣，練習也是完美的。
敏捷軟體開發