執行SCRUM-13 – 使用者故事User story(4)
而實際上故事的撰寫，通常是從使用者的觀點出發，所以常會很難解析到工作卡片。或者是故事太大、太抽象等等，無法拆分為工作卡片，所以有下列幾種方法可以來切割、重寫、釐清、定義: (精實開發看版方法/李智樺)
  1. 依照工作流程，拆解流程中的步驟，增量陸續完成。
  2. 採用業務規則，
  3. 區分主次要，再釐清使用者的主要需求，再拆解成大小不一的小故事。
  4. 簡單或複雜場景，有時考量的因素太多，讓故事無法收斂。此時先發展一個最簡單的版本，讓團隊可以依此得到成果，給使用者驗証。
  5. 陳列所有變化，針對第4點複雜場景，紀錄各項變異性，以利後續補充或修正使用者需求。
  6. 先展示體驗，有時複雜性的演化是來自開發團隊的想像，或許使用者的需求與團隊解讀不同，所以利用一個簡單版本的可行性介面、功能，可以讓雙方達成一定地共識。
  7. 降低品質，有時要完全滿足使用者需求，是需要一段長時間的努力，較不符合SCRUM快速疊代的精神，所以降低品質，期以短時間達成發布使用，讓使用者的回饋可以迅速回到開發團隊。
  8. 資料操作切割，一般的管理操作會包含新增、讀取、修改、刪除(CRUD)，一旦故事的規模較大時，可以依操作方式進行故事切割。
實務上的操作，有時要依照團隊的方式演化，例如如果1個user story展開的工作卡片來不及在1個SPRINT完成，那應該依照功能(假設完整包含6個功能)拆分成2張工作卡片，或者考量增加SPRINT的時間，讓1張工作卡片在1個SPRINT內完成，才能有效計算每個SPRINT完成的story point。