課程筆記: User Stories: A Practitioner’s Guide(下)

Orian Y.
9 min readJul 27, 2024

--

上篇筆記請見這裡:課程筆記: User Stories: A Practitioner’s Guide(上)
Udemy 課程連結:https://www.udemy.com/course/effective-user-stories/

https://pixabay.com/illustrations/book-dog-fairy-tales-child-kid-794978/

重新梳理使用者故事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、支付的故事單獨篩選出來。這麼做會導致故事零碎,無法清楚地表現故事的使用情境和價值,並且不容易理解。

為什麼不要根據技術層面拆分故事?

  1. 上下文丟失: 當故事被根據技術層面拆分時,使用情境和故事的整體價值可能會丟失,導致開發團隊對需求的理解不完整。
  2. 難以管理: 技術層面拆分的故事更像是技術任務,而非User Stories,這會使得故事的管理和優先級排序變得複雜。
  3. 價值不明: 使用者故事應該描述的是用戶的需求和期望,這樣才能確保每個故事都有明確的價值。技術層面的拆分往往無法直接反映用戶的需求和商業價值。

不知道故事該從何拆起,或是不確定故事夠不夠小、夠全面時,可以用以下的法則:

SPIDR 法則

Spikes

當不確定如何開始拆故事時,先進行研究或找到特定資訊。例如調查實踐的可能技術、工具,或是進行更深層的用戶調查。
- 例子: 故事描述支付的行為,但不確定哪種支付方式最適合。這時可以先進行一個 Spike,研究和測試不同的支付技術,再根據選定的幾個選項來拆分。

Paths

思考使用者取得服務的路徑和流程。先從最佳的路徑(Happy Path)開始思考,劃出流程圖,確定每個步驟都有故事。之後再延伸到其他可能的路徑。
- 例子: 故事描述在網站上購物結帳,Happy Path是用戶順利完成購物流程。但也需要考慮其他路徑,比如取消訂單、退貨,或是支付失敗的路徑。

Interfaces

根據不同的使用媒介、版本、管道來思考使用者會遇到的情境,例如用手機還是電腦操作;或是免費試用版和進階版的差異。
- 例子: 故事描述在App上聽音樂會顯示歌詞,但手機和運動手錶上的介面應該是不一樣的,需要分別的故事。

Data

根據不同的數據資料性質來拆分。例如不同年齡層或性別的數據,或是數據被讀取的頻率、驗證狀態等。
- 例子: 故事描述使用者想要得到特價商品折扣的資訊,可以根據使用者的性別、年齡、消費紀錄來進行更細緻的切分。

Rules

根據法律或規則來拆分,包括業務規則或技術規則,如個資法揭示標準或資料加密等非功能需求。
- 例子: 團隊正在開發一個銀行應用程式,需要遵守個人資料保護法。這時候,需要考慮歐盟和不同地區的法規,確保每個故事都符合相關規定。

除了SPIDR之外,也有其他的拆分方法,這並不是唯一的可能性,可以根據需求多多探索。

合併故事

除了拆故事之外,有時我們在重新梳理的過程,會發現有的故事可以合併。這樣做可以減少重複工作或資源浪費。例如有兩個 User Stories 的目標非常相似,都是為了支付訂閱費用,那就可以合併成一個故事。

識別使用者故事(Identify User Stories)

這裡你可能會想問,為什麼又要識別故事?不是一開始就識別過了嗎?答案是,「識別使用者故事」是在開發中不斷進行的動態過程。根據用戶需求的變化,隨時添加或淘汰故事來符合需求。所以在重新梳理故事的時候,可能會發現現有故事的不足,這時候就需要重新探索和識別新的使用者故事。

那麼,當我們發現故事不足或不夠符合需求時,有幾個方法重新識別:

  1. 從 Persona 中探索
    如同上篇提到的,這個方法適合在產品的初始階段使用,根據選出的primary persona來研究它的需求。我們可以找出Persona的資料,重新檢視是否有遺漏的考量,或是Persona發生了變化,需要重新評估。
  2. 從現有的問題中探索
    這個方法適合已經在運行的產品,根據它遇到的狀況,為它設計出新的使用者故事。例如使用者抱怨常常找不到優惠卷的位置,就可以針對這個問題,使用Lean UX Canvas模板來討論問題和解決方法。
  3. 從 Customer Journey Mapping 中探索
    這個方法適合已經在運行的產品,或是有明確的競爭產品。透過Customer Journey Mapping來找到使用者的痛點和改善機會。
  4. 從 Business Process Mapping 中探索
    這個方法適合已經在運行的產品。它類似Customer Journey Mapping,不過包含更多的服務細節,像是服務人員在哪一個環節介入,或是對應到哪個窗口等。
  5. 從 Atomise 或 Breakdown 中探索
    這個方法適合要製作已知、成熟的產品。根據常見的功能,從大到小拆分。舉例來說,團隊要建立一個線上購物網站,那麼就可以先拆成搜尋商品、瀏覽商品、結帳等主要功能。再列出更詳細的細節,例如搜尋商品可以拆為根據價格、銷售數量、評價來篩選,輸入關鍵字篩選等。
  6. 使用 CRUD 來思考數據的循環 Data Lifecycle
    CRUD是Create(創建)、Read(讀取)、Update(更新)、Delete(刪除)的縮寫,描述了數據的基本操作。每一個操作可以成為一個User Story。
    例如「圖書館App」的產品,就對應了建立新書籍檔案、搜尋書籍、更新書籍信息、刪除書籍記錄等。
  7. 從負面的使用者探索
    除了正常的使用者之外,我們也可以假設自己是對產品不利的使用者,例如競爭者、想偷顧客資料的駭客、憤怒的前員工等。描述出這些人的故事,再根據他們的故事進行防範、調整,可以讓產品更完整,也能確保這些人不會影響到正常使用者的體驗。

將使用者故事列入Backlog

經歷了重重的險阻,確認好使用者故事都齊全,並且拆分到適當的大小後,現在我們終於要進入為開發的準備!

前面提到,最小的使用者故事是可以直接交給團隊開發的,那麼它們應該要被放入Backlog裡。在這裡,講者建議使用Story Mapping來把Backlog視覺化

因為這部分課程涉及到圖片示範,很難用文字描述,因此參考了Anna Kaley的這篇文章,請見Story Mapping的範例如下。簡單來說,就是先從最高層級的故事Epic來排序,再根據對應的步驟、細節,把最小的使用者故事往下延伸(這就是為什麼一開始建議寫在便利貼上!)

from: https://www.nngroup.com/articles/user-story-mapping/

這裡有幾個重點:

  • 我們可以出不同的解決方法,來回應同一個故事。
  • 故事應該根據重要性,由上往下排序。
  • 每一條由上到下的路徑,要找出製作最小可行性產品(MVP)的界線。 這樣可以確保我們盡快提供產品給使用者測試,得到最直接的回饋,再考慮製作更多功能。
  • 除了MVP的界線,還有一條線是完整版(Fully Version)的界線。 在這之下還有的故事是屬於錦上添花(Nice to Have)的功能。

同樣的,熱愛口訣的講師提供了確認Backlog是否完整的檢查方法(DEEP)

  1. Detailed: 最優先的故事應該包含足夠的細節和考量。如果沒有,先不要開始動工。
  2. Estimated: 每個故事都被清楚地衡量大小,確保團隊理解完成它們所需的能力和時間。有些團隊會用故事點(Story Points)來顯示。
  3. Emergent: 要確認Backlog是時常被檢驗、有變化的,根據使用者的需求或現實狀況調整。
  4. Prioritized: 故事根據優先順序排列,團隊依照重要性來開發。

此外,講師也提醒,Backlog應該是公開的,團隊中的每個人都可以查看。

結論

到這裡,使用者故事從開始到進入開發的環節,都包含在內了。

講師的建議是,不要害怕寫錯,寫越多的故事,不停的改動,就會越來越好。而且他鼓勵嘗試不同的使用者故事範本(templates),因為不同的產品、環境,都有不同的需求。最重要的是,跟團隊多多溝通,一起練習寫故事、檢查故事。

那麼,我的看法是...我打算直接練習!請期待我的下一篇,根據自己的side project練習使用者故事,之後再更新連結到這篇文章中。

希望看到這裡的你,會覺得有所收穫,有什麼想法和建議,都很期待和你交流 :)

上篇筆記請見這裡:課程筆記: User Stories: A Practitioner’s Guide(上)

--

--