對於剛接觸敏捷交付的人來說，成功為項目提供動力的一個常見障礙就是整合了每個人都能理解的積壓工作。在這篇文章中，我將看看如何在項目的整個生命週期中使用“用戶故事”來回答這個問題：什麼能成為一個好的用戶故事？
創建項目願景
我們通常在Manifesto開展項目，並舉辦研討會以建立共同願景。我們將利益相關者和核心團隊聚集在一起，以確定用戶是誰，他們的需求是什麼，產品可以滿足這些需求的功能以及功能創建的價值（包括用戶和業務）。
然後核心交付團隊討論我們將如何實際交付工作。這涉及回答以下問題：
- 我們將使用什麼方法來管理項目？（看板，Scrum或混合）
- 我們會寫什麼樣的用戶故事？
- 誰會擁有積壓？
- 我們的衝刺週期會持續多長時間？
- 什麼時候準備開發的故事（Ready的定義）？
- 故事什麼時候完成（完成的定義）？
這些是關鍵決策，將影響項目其餘部分的順利交付。
填充待辦事項
下一步是將產品視覺會話中的“功能”轉換為用戶故事。這些將填充開發積壓，將在整個項目的其餘部分使用。在實踐中，考慮誰擁有這個過程是很有趣的。這是項目經理？產品負責人？也許是業務分析師或團隊中的其他人？在宣言中，答案是：每個人。這是我們如何做到的。
在這個階段，用戶故事只需要用廣泛的畫筆筆劃來描述這個特徵 - 我們不打算開始構建這個特徵 - 但是最好是根據用戶是誰，他們需要什麼以及價值來做到這一點。該功能增加了。
例如：
作為一個喝茶的人，我想用手柄拿起我的茶，這樣我就不會燒手。
任何閱讀故事的人不僅知道它所描述的特徵，還知道該特徵的用途以及為什麼提供它。
製作此初始積壓可以是協作工作，也可以由團隊之一負責。它最終由產品負責人批准，產品負責人將確認它是否代表最終產品。
改善積壓
現在是時候將一些關鍵的團隊成員聚集在一起，開始充實故事。
你不需要整個團隊（這很好，因為在項目開始之前讓所有人聚在一起通常是不可能的）。我們希望至少使用“三個朋友” - 產品負責人（或BA），開發人員和設計師（或UX設計師）來優化積壓。
這次會議的目的是優先考慮和估計積壓的故事大小，但在我們能夠做到這一點之前，我們需要勾勒出我們的想法和提出的解決方案。在這個階段，您可能會發現一些原始故事被分解為幾個組件故事。
例如，我們之前的故事可能會變成一個包含以下故事的史詩：
作為一個喝茶的人，我想把我的茶放在一個杯子裡，以便我可以拿起它。
作為一個喝茶的人，我希望我的杯子有一個把手，這樣我就不會燒手。
細化會議旨在梳理這種細節。特別是，我們希望為每個故事提供一套接受標準，以便我們知道故事何時完成。我們喜歡將接受標準寫成'Given，When，Then'格式的場景，這種格式設置了非常清晰的測試（如果您願意，甚至可以將這些測試腳本轉換為自動測試腳本），例如
鑑於我是'喝茶的人'
當我訪問'我的飲料'
然後我看到'一個帶把手的馬克杯'
通過對每個故事進行這個過程，很快就會清楚每個故事是否具有可測試的大小。
Sprint計劃會議
Sprint Planning是我們確定實際工作方式並同意我們將在其上工作的訂單的地方。作為一個代理商，在我們計劃第一個sprint之前，我們經常會向客戶提出我們提出的解決方案，甚至可能是積壓本身，提供進一步發現錯誤或誤解的機會，並進一步完善積壓工作。內部團隊可能希望通過向主要利益相關者演示他們的解決方案來複製這個機會。
sprint計劃需要整個團隊。這不僅是他們能夠找到他們正在進行的工作的地方，而且還是一個機會，可以完成所需的任務，挑戰任何先前的假設，包括估算，並檢查故事和驗收標準是否真的可以用於開發。通常會編寫和估計新故事，因為那些被認為對於單個衝刺而言太大的故事會被分解為更易消化的部分。
在會議結束時，應該確定第一個衝刺的積壓，包括驗收標準，以及需要前端開發的故事，草圖和線框。
衝刺
從理論上講，這些故事具有開發人員將其轉化為工作特徵所需的所有細節。實際上，一兩個不發達的故事可能已經在網絡中滑落（可能在計劃結束時，每個人都有點萎靡不振）。
不用擔心。只要你的團隊溝通良好（你每天都站起來，不是嗎？）那麼應該有很多機會根除那些薄薄的故事，重寫驗收標准或在必要時重新繪製線框並讓它們重新進入衝刺積壓。
如果這個sprint的故事無法恢復，那麼，如果它描述了一個功能，而不是一大堆功能，那麼你應該能夠在不影響其餘衝刺的情況下對其進行掃描。以敏捷方式工作的最好的事情之一就是我們可以在不破壞整個項目的情況下處理這樣的問題。
接受標準現在真正自成一體，因為它們用於確定哪些故事符合所有驗收測試並且可以被視為完成或準備發布。
演示
隨著衝刺，我們應該有一個工作的軟件，我們可以向客戶/利益相關者演示。在演示會議期間，用戶故事提供了一個良好的框架來報告已完成的工作和尚待完成的工作。
這也是利益相關者對產品進行反饋並提出改進建議的機會。這些建議可以由產品負責人編寫為新的用戶故事，並帶到下一個積壓改進會議。
回顧會議
敏捷重視人員和流程與工具之間的互動，因此我們應該聚在一起討論我們已經完成的工作，以及我們如何在每個sprint之後更好地協同工作。如果我們不在衝刺中工作，那麼我們應該至少經常聚在一起進行回顧，以便我們能夠根據我們的見解採取行動。
在回顧會議中，用戶故事本身通常在討論通信工具，會議結構等方面退居次要，但試圖找時間討論是否需要解決“完成和準備”的定義以及接受標準的充分性（或不充分性） 。
這是一個不斷迭代和改進的過程，但目標是找到一致的用戶故事“模板”，使功能易於理解，並清晰地說明故事何時為其生命週期的下一階段做好準備。
