實際的開發過程中，我們運用如禪道、TAPD等團隊協作軟件建立管理用戶故事，對于故事我們就可以進行更加豐富的記錄。

一個完整的用戶故事需要寫的內容包含：

展現形式如下：

一、故事標題

用戶故事的描述在列表中進行管理時，不利于快速理解，也不能一行展示。為每個故事取個標題（名字）就很有必要，而且像禪道、TAPD軟件的需求表述格式中標題也是必填項。

就行郵件的主題，用戶故事的標題是為了讓讀者能快速了解這個用戶故事的要點和大致范圍；怎么寫好標題也是有章可循的。
常見的做法有：

1. 用戶角度的動賓短語

如：創建商品、輸入名稱、修改頭像等等這是動作+對象形式，擅長描述從用戶看到的活動或功能。

2. 系統角度的動賓短語

此處的系統是指待開發的對象。

如，toast提示網絡異常，記錄用戶訪問次數，顯示搜索結果，顯示倒計時。擅長描述系統要執行的反饋和操作。

3. 主謂賓短語

有時動賓短語不能推斷主語時使用主謂賓短句，或者可能有可能混淆時需要明確主語，此時就需要增加動作主語，如，超級管理員重置普通管理員的口令；A系統推送批量客戶和合同信息。

隨著時間推移，新增的用戶故事有不少是基于原有的功能來再提升修改，這時往往要在標題里加上狀語來區分，比如根據客戶所在城市來查詢客戶列表，在客戶沒有登記電話號碼時強制客戶登記號碼。 狀語要清晰得說明用戶故事所處的情況，能夠區分類似的用戶故事。

4. 差勁標題舉例

（1）外訪業務處理

點評：處理是萬金油詞語，沒有突出重點。

（2）設計資產逾期流入流出報表

點評：主語既不是用戶，也不是待開發的系統，而是開發人員，這更像是一個任務的標題。

（3）角色分配資源

點評：要做什么呢？不能快速理解故事核心。

二、故事描述

固定格式“作為……（用戶角色），我想要……（完成活動），以便于……（實現價值）”的格式。故事描述一這種三段式表述，相比較于傳統需求表述，體現了需求方和需求價值的重要性，也為保證了需求描述的可協商性。

三、規則描述

為了完成故事，有時需要制定故事的實現規則，涉及的名詞定義等。規則描述由產品經理初步制定，在故事討論后，進行修訂確認。寫作方式就是一條條窮舉列出。注意這里不涉及原型頁面和交互規則。

四、驗收標準

可作為驗收測試用例的具體例子。這也是我們常說的實例化需求，也是為了避免誤讀，讓抽象的需求變得具體和可測試。
這一步很難，但非常重要。沒有明確的驗收條件，我們便不知道如何測試，業務也不知道如何驗收。

通常，一個用戶故事包含若干個驗收條件，包括快樂路徑（Happy Path）與意外場景（Exceptional Scenario）。

建議將驗收條件全部寫成“Given…When…Then”的 Gherkin 語言格式，這種寫法和測試用例類型，是一條條具體的路徑/場景，信息傳遞誤差小。延伸開來，這一原則適用于任何事情。做一件事情，以終為始，在一開始明確要做成什么樣子，行成閉環，才能指導行動并確保結果正確。

五、具體設計方案

故事完成需要具體的執行方案，方案一般都有故事實現的原型界面，交互規則；如果是數據類故事需求，還有數據指標的定義等。具體設計方案的產出可以在故事確認前也可以在故事確認后，具體看產品的時間和團隊的要求。

方案文件一般為附件或原型鏈接。

六、上線檢查清單

有些用戶故事的上線可能需要一些額外的步驟，在做用戶故事開發時就應該時刻想著上線時要留意的問題，及時記錄作為備忘，以確保上線成功。
這里，確認理解、問為什么以及驗收條件是重點，作為“就緒定義”（Definition of Ready, DoR），幫助我們厘清用戶故事的具體需求。

系列文章目錄

用戶故事（一）：什么是用戶故事？

用戶故事（二）：為什么要使用用戶故事表達需求？

用戶故事（三）：用戶故事該怎么寫？

參考文章

用戶故事之好標題

本文由 @chun 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。