上篇筆記請見這裡：課程筆記: User Stories: A Practitioner’s Guide(上)
Udemy 課程連結：https://www.udemy.com/course/effective-user-stories/
重新梳理使用者故事User Stories
我們在上篇筆記講述了如何開始寫使用者故事User stories，但是在寫完之後，必須重新梳理故事(Refinement)，才能將故事轉換為開發內容。
使用者故事的規模 Size of User Stories
每一個故事可以根據它包含的內容、範圍、細節，來判定它的大小，就像小說一樣，長篇的哈利波特和短篇散文所包含的範圍完全不同。這個判斷應該由團隊一起討論，找出使用者故事規模的共識。我們由大到小來介紹：
Epic = 最大的故事 (史詩)
- 它通常不會包含太多細節，是對產品或服務的廣泛描述。例如：「身為一個健身教練，我想要一個能找到潛在學員的工具，幫我拓展客源。」這是非常高層級的描述，團隊無法直接用這個故事開始開發，因為很多細節都不清楚：是什麼樣的工具？如何定義潛在學員？
不過，雖然大故事很模糊，但它可以幫助團隊了解產品的整體目標，並設定一定的範圍，釐清界線。
Features = 中等故事 (功能)
- 它介於最大的Epic和最小的User Stories之間，通常是根據產品的功能來拆分。例如，前面提到的健身教練需求，就可以拆分為「搜尋學員」、「聯繫學員」、「支付課程費用」等針對特定功能的故事。
Themes = 中等故事 (主題)
- 也有人稱它為Initiatives，是將有相同特性或關聯的多個User Stories綁定在一起的方式。它可以幫助團隊更好的安排開發進度，也可以協助範圍確認，避免遺漏某些功能。例如，所有關於「使用者帳號管理」的故事可以歸類在一起，成為一個主題，在同一時間開發。
User Stories = 最小的故事
- 它是最終的目標，是小到可以直接交給團隊開發的獨立故事，清楚地描述需求、功能和驗收標準（請見上篇的INVEST檢查方式）。例如「身為一使用者，我要用生物辨識功能登入，這樣才能確保我的使用安全」。
請注意，不同團隊和公司，在故事的名稱可能上有不同的用法，但Epic和User Stories是最常見的。
如何拆分使用者故事 (Break Down User Stories)
在了解使用者故事的規模後，我們要把太大的故事拆成最小的、可開發的User Stories。這裡要提醒的是，不要根據技術層面來拆分，例如根據前端或後端來拆分，或是把關於UX、支付的故事單獨篩選出來。這麼做會導致故事零碎，無法清楚地表現故事的使用情境和價值，並且不容易理解。
為什麼不要根據技術層面拆分故事？
- 上下文丟失： 當故事被根據技術層面拆分時，使用情境和故事的整體價值可能會丟失，導致開發團隊對需求的理解不完整。
- 難以管理： 技術層面拆分的故事更像是技術任務，而非User Stories，這會使得故事的管理和優先級排序變得複雜。
- 價值不明： 使用者故事應該描述的是用戶的需求和期望，這樣才能確保每個故事都有明確的價值。技術層面的拆分往往無法直接反映用戶的需求和商業價值。
不知道故事該從何拆起，或是不確定故事夠不夠小、夠全面時，可以用以下的法則：
SPIDR 法則
Spikes
當不確定如何開始拆故事時，先進行研究或找到特定資訊。例如調查實踐的可能技術、工具，或是進行更深層的用戶調查。
- 例子： 故事描述支付的行為，但不確定哪種支付方式最適合。這時可以先進行一個 Spike，研究和測試不同的支付技術，再根據選定的幾個選項來拆分。
Paths
思考使用者取得服務的路徑和流程。先從最佳的路徑（Happy Path）開始思考，劃出流程圖，確定每個步驟都有故事。之後再延伸到其他可能的路徑。
- 例子： 故事描述在網站上購物結帳，Happy Path是用戶順利完成購物流程。但也需要考慮其他路徑，比如取消訂單、退貨，或是支付失敗的路徑。
Interfaces
根據不同的使用媒介、版本、管道來思考使用者會遇到的情境，例如用手機還是電腦操作；或是免費試用版和進階版的差異。
- 例子： 故事描述在App上聽音樂會顯示歌詞，但手機和運動手錶上的介面應該是不一樣的，需要分別的故事。
Data
根據不同的數據資料性質來拆分。例如不同年齡層或性別的數據，或是數據被讀取的頻率、驗證狀態等。
- 例子： 故事描述使用者想要得到特價商品折扣的資訊，可以根據使用者的性別、年齡、消費紀錄來進行更細緻的切分。
Rules
根據法律或規則來拆分，包括業務規則或技術規則，如個資法揭示標準或資料加密等非功能需求。
- 例子： 團隊正在開發一個銀行應用程式，需要遵守個人資料保護法。這時候，需要考慮歐盟和不同地區的法規，確保每個故事都符合相關規定。
除了SPIDR之外，也有其他的拆分方法，這並不是唯一的可能性，可以根據需求多多探索。
合併故事
除了拆故事之外，有時我們在重新梳理的過程，會發現有的故事可以合併。這樣做可以減少重複工作或資源浪費。例如有兩個 User Stories 的目標非常相似，都是為了支付訂閱費用，那就可以合併成一個故事。
識別使用者故事（Identify User Stories）
這裡你可能會想問，為什麼又要識別故事？不是一開始就識別過了嗎？答案是，「識別使用者故事」是在開發中不斷進行的動態過程。根據用戶需求的變化，隨時添加或淘汰故事來符合需求。所以在重新梳理故事的時候，可能會發現現有故事的不足，這時候就需要重新探索和識別新的使用者故事。
那麼，當我們發現故事不足或不夠符合需求時，有幾個方法重新識別：
- 從 Persona 中探索
如同上篇提到的，這個方法適合在產品的初始階段使用，根據選出的primary persona來研究它的需求。我們可以找出Persona的資料，重新檢視是否有遺漏的考量，或是Persona發生了變化，需要重新評估。 - 從現有的問題中探索
這個方法適合已經在運行的產品，根據它遇到的狀況，為它設計出新的使用者故事。例如使用者抱怨常常找不到優惠卷的位置，就可以針對這個問題，使用Lean UX Canvas模板來討論問題和解決方法。 - 從 Customer Journey Mapping 中探索
這個方法適合已經在運行的產品，或是有明確的競爭產品。透過Customer Journey Mapping來找到使用者的痛點和改善機會。 - 從 Business Process Mapping 中探索
這個方法適合已經在運行的產品。它類似Customer Journey Mapping，不過包含更多的服務細節，像是服務人員在哪一個環節介入，或是對應到哪個窗口等。 - 從 Atomise 或 Breakdown 中探索
這個方法適合要製作已知、成熟的產品。根據常見的功能，從大到小拆分。舉例來說，團隊要建立一個線上購物網站，那麼就可以先拆成搜尋商品、瀏覽商品、結帳等主要功能。再列出更詳細的細節，例如搜尋商品可以拆為根據價格、銷售數量、評價來篩選，輸入關鍵字篩選等。 - 使用 CRUD 來思考數據的循環 Data Lifecycle
CRUD是Create（創建）、Read（讀取）、Update（更新）、Delete（刪除）的縮寫，描述了數據的基本操作。每一個操作可以成為一個User Story。
例如「圖書館App」的產品，就對應了建立新書籍檔案、搜尋書籍、更新書籍信息、刪除書籍記錄等。 - 從負面的使用者探索
除了正常的使用者之外，我們也可以假設自己是對產品不利的使用者，例如競爭者、想偷顧客資料的駭客、憤怒的前員工等。描述出這些人的故事，再根據他們的故事進行防範、調整，可以讓產品更完整，也能確保這些人不會影響到正常使用者的體驗。
將使用者故事列入Backlog
經歷了重重的險阻，確認好使用者故事都齊全，並且拆分到適當的大小後，現在我們終於要進入為開發的準備！
前面提到，最小的使用者故事是可以直接交給團隊開發的，那麼它們應該要被放入Backlog裡。在這裡，講者建議使用Story Mapping來把Backlog視覺化。
因為這部分課程涉及到圖片示範，很難用文字描述，因此參考了Anna Kaley的這篇文章，請見Story Mapping的範例如下。簡單來說，就是先從最高層級的故事Epic來排序，再根據對應的步驟、細節，把最小的使用者故事往下延伸（這就是為什麼一開始建議寫在便利貼上！）
這裡有幾個重點：
- 我們可以出不同的解決方法，來回應同一個故事。
- 故事應該根據重要性，由上往下排序。
- 每一條由上到下的路徑，要找出製作最小可行性產品（MVP）的界線。 這樣可以確保我們盡快提供產品給使用者測試，得到最直接的回饋，再考慮製作更多功能。
- 除了MVP的界線，還有一條線是完整版（Fully Version）的界線。 在這之下還有的故事是屬於錦上添花（Nice to Have）的功能。
同樣的，熱愛口訣的講師提供了確認Backlog是否完整的檢查方法(DEEP)：
- Detailed： 最優先的故事應該包含足夠的細節和考量。如果沒有，先不要開始動工。
- Estimated： 每個故事都被清楚地衡量大小，確保團隊理解完成它們所需的能力和時間。有些團隊會用故事點（Story Points）來顯示。
- Emergent： 要確認Backlog是時常被檢驗、有變化的，根據使用者的需求或現實狀況調整。
- Prioritized： 故事根據優先順序排列，團隊依照重要性來開發。
此外，講師也提醒，Backlog應該是公開的，團隊中的每個人都可以查看。
結論
到這裡，使用者故事從開始到進入開發的環節，都包含在內了。
講師的建議是，不要害怕寫錯，寫越多的故事，不停的改動，就會越來越好。而且他鼓勵嘗試不同的使用者故事範本(templates)，因為不同的產品、環境，都有不同的需求。最重要的是，跟團隊多多溝通，一起練習寫故事、檢查故事。
那麼，我的看法是...我打算直接練習！請期待我的下一篇，根據自己的side project練習使用者故事，之後再更新連結到這篇文章中。
希望看到這裡的你，會覺得有所收穫，有什麼想法和建議，都很期待和你交流 :)
