在當下，處于VUCA時代的我們也在面臨着來自客戶的易變、不确定、複雜化、模糊化的需求。這種多變的需求推動着我們要加強與客戶的溝通交流，通過使用者故事來澄清客戶需求，幫助客戶打造對他們來說有價值的産品。是以我們該怎樣澄清使用者故事呢？
一、誰來編寫使用者故事？
使用者故事是由誰來寫呢？一般情況下， 一定是最接近使用者的角色來負責編寫使用者故事，這個角色一般情況下是客戶或者産品負責人。通常客戶寫出來的需求也不能稱為嚴格意義上的使用者故事，這就需要産品負責人在與客戶确認的基礎上再加工，形成一個完整的使用者故事。
如果在某個團隊中，使用者故事是由測試人員或開發人員編寫的，那我們也同樣需要明确這個使用者故事是經過客戶和産品負責人确認過的。同樣， 使用者故事優先級的排序也是需要最貼近使用者側的人員來進行确定，如果研發團隊自行決定使用者故事的優先級，那麼就有可能出現最先實作的使用者故事有可能不是最重要的，而是最好實作的。
那如何編寫使用者故事呢？可以通過對使用者的訪談、市場調查等方式來發掘使用者需求，然後按照INVEST原則來合理編寫使用者故事。
在這個階段，我們要注意的一個事情是，為了達成靈活團隊的自組織，提高團隊成員的積極性與參與感，我們可以不明确到底是誰來編寫使用者故事，而是讓每一位團隊成員都參與編寫使用者故事。這樣的話能夠激發團隊成員的責任意識，減少成員之間的互相推诿。
二、什麼時候使用使用者故事？
使用者故事明确了什麼角色想要什麼功能，以便于實作什麼價值或目的。是以在每實作一個功能之前，我們 要明确為什麼要做這個功能以及怎樣才能達成這個目的或價值。
但我們需要注意的是，不是所有的任務都需要用使用者故事來表達，比如團隊的一些事務性的功能就可以以任務的形式而非使用者故事的形式來表達，因為這類事項不能産生對客戶有益的價值。對于能夠直接對客戶産生價值的需求，我們可以用使用者故事來表達。
是以，我們要真正弄清楚真正面對使用者的使用者需求（使用者回報的Bug、撰寫使用者手冊的需求、産品功能性需求等），我們通過使用者故事來表達；而一些團隊内部的改進問題（如進行結對程式設計、内部發現的代碼規範、某一部分的代碼重構等），我們可以用團隊達成共識的表述方式來呈現。
三、使用者是誰？
在做項目管理的時候，我們一定要與使用者接觸、溝通，了解使用者的真實需求和實際的使用場景。在一般情況下，很多公司隻有銷售人員在接觸客戶，研發側人員以及産品負責人等離客戶非常遠，那在這種情況下，團隊很容易出現“閉門造車”的現象，最終傳遞的東西無法投入到實際應用環境中，也不是使用者真正需要的。
是以整個技術團隊需要搞清楚使用者是誰、使用者在哪以及使用者有什麼需求這幾個問題。而在這個時候，我們可以用使用者畫像、影響地圖、使用者故事地圖、同理心地圖、客戶旅程地圖等實踐（這些實踐可以在融·軟體項目管理推薦庫中進行了解）找出真正的使用者，進行精準的需求擷取。而針對一些中間件、微服務等，我們可以通過将這些中間件及微服務的上下遊系統定義為系統使用者，也能夠比較輕松地編寫出這些系統使用者的使用者故事。
四、使用者故事規範
使用者故事的規範其實也是一個常見問題，我們可以通過一個小視訊來詳細了解如何來編寫使用者故事： 如何寫好使用者故事？
五、勿以唯故事點論
雖然我們在估算使用者故事的時候會使用故事點估算，但過度地關注故事點也會讓我們适得其反。首先我們要明确的是 故事點估算沒有一個統一的标準，每個團隊都可以根據自身的實際情況确定自己的基準故事點。
這裡有幾個關鍵環節我們要注意：在實際完成某一疊代的時候，我們要關注這個疊代傳遞了多少功能，而不是完成了多少故事點；不要做團隊與團隊之間的故事點橫向對比，因為兩組并不是完全一樣的條件，是以沒法進行直覺地對比；我們隻用故事點來執行疊代計劃，不應該将故事點與績效管理挂鈎。
六、定義“就緒”“完成”與“驗收标準”
在使用者故事被放入疊代計劃之前，我們要确認使用者故事的“就緒”狀态。團隊之間要就“就緒定義”達成共識，比如共同制定出一個檢查清單，通過此檢查清單的使用者故事即為“就緒”，可以排進疊代計劃中。同時，可以根據使用者故事的類型來制定不同類型的使用者故事“就緒定義”。此外，還有一個關鍵點在于，“就緒定義”需要定期檢查更新。
既然明确了使用者故事的“就緒”，那麼我們也要明确使用者故事的完成标準。如果我們對使用者故事完成沒有一個統一的标準，那麼就會出現研發人員覺得寫完代碼就算完成了，而測試人員認為編碼後自測、然後通過功能測試之後才算完成的情況，這種情況會大大增加溝通成本，降低工作效率。
是以團隊需要給使用者故事一個完成的定義，比如通過自測、功能測試、內建測試才能算使用者故事的“完成”，也就是我們所說的“DoD”。
那使用者故事完成了，它能達到使用者的滿意嗎？這裡就牽扯出了一個細節問題，團隊制定的使用者故事的“完成定義”隻是确認了這個使用者故事或這個功能做完了，但是并不能明确這個功能可以滿足使用者的需求。那為了解決滿足使用者需求這一問題，我們可以設定使用者故事的驗收标準。
驗收标準的設定需要使用者、産品負責人及團隊一起來讨論完成，它能夠滿足最初的使用者故事的内容。也就是說，如果我們要做一個網站注冊功能，最終做出來了一個通過郵箱号完成注冊的功能，這個功能是通過自測、功能測試後明确完成了的功能，但是使用者希望能夠通過手機号直接注冊，這個完成了的功能并未滿足使用者的需求。那這樣的話我們做出來的功能并不是使用者所期望的，是以我們要通過驗收标準來滿足使用者的期望。
- Given：鑒于我的角色是網站未注冊使用者；
- When：當我點選網站右上角的“注冊”按鈕；
- Then：系統就會彈出注冊頁面；
- When：當我輸入手機号，點選發送驗證碼，并填寫收到的驗證碼，點選“注冊”；
- Then：系統顯示登入成功。