實行敏捷開發的團隊大部分都會用 User Story 來梳理使用者的需求，依照團隊的情況，每個團隊實行的方式也不盡相同，看起來差不多，可是細節卻有差。
User Story 看似簡單，操作起來卻有很多地方需要注意，一不小心很容易成為災難一場，不僅徒勞無功，又累死三軍，下面記錄我最近一次使用 User Story 的經驗，過程多少有一些操作得不是很好的地方，把它寫下來後，希望可以做為我未來調整及修正的方向。
事前準備
在開始之前有一些工具需要準備，首先是一個超大的白板（沒有的話就用全開圖畫紙拼起來也可以）、各種顏色的狠黏便利貼（一定要狠黏的，因為曾經聽過便利貼掉到地上，被清潔阿姨掃走了一整堆的事情。），之前到趨勢參加 Agile Meetup，看到整面牆是一整塊的超大白板，就一整個大心。
有些人會用 Trello 之類的電子化工具來取代白板跟便利貼，其實我還蠻堅持用實體的便利貼來做 User Story Card，原因是因為 User Story Card 是用來引起對話跟產生共鳴的，它是讓整個專案團隊拿來討論並達成共識的，而電子化的工具無法把專案團隊聚焦在使用者的需求面前，很難讓目前被討論的項目快速地在團隊成員之間傳遞，因為當物有所指的時候，人的思緒是會比較容易被拉到那件事情上。
再來是少不了的白板筆（寫白板用的）、細字簽字筆（寫便利貼用的，建議不要用原子筆。）、膠帶、強力磁鐵（用來吸住全開圖畫紙）、共同編輯系統（我推薦的是 Evernote），最後是祭五臟廟少不了的食物（飲料、零食…等等）。
使用者故事
User Story 顧名思義它是一個故事，它用簡單的格式來描述使用者的需求 As a 人物／角色, I want 做什麼事情／什麼工具 so that 某個有價值的理由，我們經常會忽略一件事情，專注於用格式寫下一堆使用者故事，卻忘了去講使用者的故事，寫下一個使用者故事的同時，就應該要去說一個使用者的故事，讓專案團隊了解我們做的事情對使用者有什麼影響？能夠幫助使用者解決什麼問題？
需求訪談
我們期望使用者就在我們的周遭，隨時可以與使用者進行討論，以清楚了解使用者的需求，但不是每個專案都有如此的環境，也因為如此，專案團隊當中至少要有一位，甚至一位以上能夠先與使用者接觸，深入地去了解使用者的問題及痛點。
有一點要特別注意，我們常常會以為使用者開出來的藥方就是使用者的需求，其實這是一種謬誤，比如說，使用者要在系統中加一個「新增客戶資料」的功能，我們以為這就是使用者的需求，但有可能他背後想要解決的問題只是在他服務客戶的同時，如果客戶資料不在 CRM 系統內，可以順便新增客戶資料，我們如果專注在這個問題上，或許就有另外一個做法，可以在客戶聯絡使用者之前，就請客戶先提供客戶資料讓系統自動建檔，不只 CRM 系統內已經有客戶資料，還可以讓使用者事先得知是哪一位客戶聯絡他，以便主動進行聯絡。
使用者面臨的問題及痛點才是使用者的需求，如果我們經常不去探究使用者為何開出這樣的藥方，那麼出現蚊子系統、蚊子功能，或是做出來的工具無法解決使用者的問題…等等的狀況，也會經常地發生，為了避免這種情形，我們可以試著使用 5 Whys 方法，反覆地提出疑問來找出問題的根本原因，通常我問到與人力、金錢、時間…等跟資源及老闆（付錢的那個人）相關的原因時，我就不再問下去了。
Refinement Meeting（Grooming Meeting）
Breakdown
當我們了解使用者的問題及痛點之後，就會得到第一批最原始的 User Story，這時候我們就可以來製作 User Story Card，Refinement Meeting 的時間長短就看專案的大小，就我的經驗而言，不要妄想在 1 ~ 2 小時之內可以搞定，它消耗的時間是以天計。
Refinement Meeting 的與會成員，理想狀況當然是希望使用者可以跟專案團隊一同與會，不過沒辦法事事都順如人意，但是起碼 PO（PM）及當初去跟使用者做需求訪談的那些人以及開發團隊都要與會，人不齊的話我會選擇延後舉行，我還沒有那個功力去舉行一個人都找不齊的 Refinement Meeting。
由 PO（PM）開始，在便利貼上寫下「誰（人物／角色）？想要（做什麼事／什麼工具）？」，並且在便利貼上標上編號，貼到白板後，講述「為什麼？」及「需求來源的故事」，底下的人也不是閒閒沒事做，要在共編系統或筆記本上記錄下講述的內容，然後用 5 Whys 來提出疑問，直到與人力、金錢、時間…等跟資源及老闆有關的原因時，就可以停止了。
接著由開發團隊上場，評估剛才成立的 User Story Card，要滿足它的話需要做哪些事情，也用便利貼一張一張寫下來，而這些事情要多細？它其實就是開發動作的可理解抽象行為（抱歉，我無法用文字表達出這種感覺，關於這一點有疑問的朋友，我們互相交流一下。），寫下來後貼在跟 User Story Card 一起，沒有異議之後再進行下一個 User Story。
在會議進行當中任何人都可以提出 User Story，並且講述「為什麼？」及「故事」，被 PO（PM）認同之後就可以成為專案需求的一部分，然後 User Story Card 不要寫成這樣：
- 「身為專案經理，我要你做一個檔案上傳程式，為了滿足使用者需求。」
- 「身為使用者，我想要一個檔案上傳程式，為了可以上傳檔案。」
也不要有這樣的心態：
- 反正不一定是我做，即使我覺得做不到，發表意見反而秀下限，我還是先潛水吧。
- 搞這些有的沒的，找個人把所有細節規劃好，然後告訴我怎麼做不是比較快？
Estimation
把所有 User Story 全部都梳理完畢之後，我們就要來對這些一群一群的 User Story Card 做預估，預估的方式你可以用 Dog Point Game、T-Shirt Size、Planning Poker，我是用 Manday Card，玩法就跟 Planning Poker 一樣，好處是比較直覺，而且預估完後 PO（PM）可以直接轉成預估時程跟使用者提案。
當我們有一個預估值出來之後，就在一群一群的 User Story Card 內找一張當代表，把這個預估值填到 User Story Card 的右下角。
最後就是請 PO（PM）去排序 User Story Card，看哪些要先做，哪些要後做，並且依照故事的骨幹順一遍 User Story Card，User Story Mapping 就出來了，接著看我們想要 run 哪個敏捷開發方法，就可以開始了。
這樣子做的 Refinement Meeting 是很冗長、很消耗精神力的，我們也可以把它拆到每個 Iteration 之前去做，最怕的就是離題，在討論的過程當中，一定要記得不停地聚焦在使用者的問題及專案的目標，專案的執行過程也要不停地去調整方向，對準使用者的問題及專案的目標。
心得
使用 User Story 要掌握一個重點，User Story 是拿來討論，引起對話，進而溝通達成共識的，如果 PO（PM）只是用 Excel 列出所有的 User Story，然後就交給開發團隊去開始進行開發工作，完全不說故事、不討論、不溝通，那可以看看董大偉老師的這篇七種摧毀開發團隊與軟體專案的上好辦法。
