本文轉自：Scrum中文網

使用者故事可能是捕獲產品功能的最流行的敏捷技術：使用使用者故事很容易。但講出有效的故事可能很難。以下十個技巧可以幫助您建立好的故事。

1. 使用者第一

顧名思義，使用者故事描述了客戶或使用者如何使用產品，它從使用者的角度進行表達。另外，使用者故事特別有助於捕捉特定的功能，例如搜尋產品或進行預訂。下圖說明了使用者，故事和產品功能（由圓圈表示）之間的關係。

如果你不知道誰是使用者和客戶，以及為什麼他們會想要使用這個產品，那麼你不應該寫任何使用者故事。首先進行必要的使用者研究，例如通過觀察和訪問使用者。否則，就有基於自己的想法和信念寫出假想的故事的風險，而不是基於資料和經過驗證的證據。

2. 使用角色來發現正確的故事

捕捉使用者和客戶的見解的一個很好的技術就是使用人物角色（Persona）。人物角色是基於目標群體的第一手知識的虛構人物。他們通常由一個名字和一張照片組成，還包括相關的特徵、行為和態度、以及一個目標。目標是人物想要獲得的利益，或者人物想要通過使用產品來解決的問題。

除此之外還有：人物角色的目標可以幫助你發現正確的故事：問問自己，為了達到人物角色的目標，產品應該提供什麼樣的功能。正如我在“ 從角色到使用者故事” 的文章中解釋的那樣。您可以從romanpichler.com/tools/persona-template下載一個方便的模板來描述您的角色。

3. 合作創作故事

使用者故事旨在作為一種輕量級的技術，使您能夠更快。他們不是一個規範，而是一個協作工具。故事不應該交給開發團隊。相反，他們應該被嵌入到一個對話中：  產品負責人（PO）和團隊應該一起討論這些故事。這使您只能捕獲最少量的資訊，減少開銷並加速交付。

您可以進一步採取這種方法，讓團隊協作來寫故事，這可以是產品backlog梳理過程中的一個環節。如果你不能讓開發團隊參與使用者的故事工作，那麼你應該考慮使用另一種更正式的技術來捕獲產品功能，例如用例。

4. 保持你的故事簡單和簡潔

寫下你的故事，以便他們很容易理解。保持簡單和簡潔。避免混淆和模稜兩可的條款，並使用主動語態。專注於重要的東西，而忽略其餘的東西。下面的模板將使用者或客戶建模為一個人物角色，並使其好處明確。它基於Rachel Davies的流行模板，但是我已經用人物角色（Persona）替換了使用者角色（Role of User），將故事與相關角色聯絡起來。

作為<persona>,

我想要<what？>

以便<why？>。

有用時使用該模板，但不要總是使用它。嘗試用不同的方法來寫你的故事，以瞭解什麼對你和你的團隊最有效。

5.從Epics開始

史詩是一個大而粗略，粗糙的故事。它通常會隨著時間的變遷而分解成多個使用者故事 – 基於使用者對早期原型和產品增量的反饋。你可以把它看作是一個標題和一個更詳細的故事的佔位符。

從史詩故事開始，能夠讓你在不關注太多產品詳細資訊的情況下捕獲產品的功能。這對於描述新的產品和功能特別有幫助：它可以讓您捕捉到粗略的範圍，這節省了你瞭解如何最好地滿足使用者的需求的時間。

這也減少了整合新想法所需的時間和精力。如果在產品Backlog中有很多詳細的故事，那麼將反饋和對應的條目關聯起來往往是非常棘手和耗時的，並且還有導致資訊不一致的風險。

6.細化故事，直到準備就緒

把你的史詩分成更小，更詳細的故事，  直到準備就緒：清晰，可用，可測試。所有的開發團隊成員應該對故事的意義有一個共同的理解; 這個故事不應該太大且能放到一個Sprint，還必須有一個有效的方法來確定故事是否完成。

7.新增驗收標準（AC）

當你把史詩分成更小的故事時，請記住新增驗收標準。驗收標準補充敘述：它們用來描述故事達到完成必須完成的條件。驗收標準豐富了故事，使其成為可測試的，並確保故事可以演示或釋出給使用者和其他干係人。作為一個經驗法則，我喜歡給詳細的故事新增三到五個驗收標準。

8.使用紙卡

使用者故事出現在極限程式設計（XP）中，早期的XP文獻講述了故事卡而不是使用者故事。有一個簡單的原因：使用者故事被捕獲在紙卡上。這種方法提供了三個好處：首先，紙卡便宜且易於使用。其次，他們促進合作：每個人都可以拿一張卡片並記下一個想法。第三，卡片可以很容易地分組在桌子或牆上，以檢查一致性和完整性，並可視化依賴關係。即使你的故事是以電子方式儲存的，當你寫新的故事時，使用紙卡也是值得的。

9.保持你的故事可見和可訪問

故事要傳達資訊。因此，不要將其隱藏在你的伺服器和電腦上。你可以把它們放在牆上，使它們可見。這會促進協作，建立透明度，而且你可以很快的發現你過快地添加了太多的故事，因為你的牆面快用完了。

我有一個方便的工具可以幫助你來發掘、視覺化和管理你的故事，這就是我的產品畫布。

如下所示。

10 不要單靠使用者故事

創造出色的使用者體驗（UX）需要的不僅僅是使用者故事。使用者故事有助於捕捉產品功能，但不能很好地描述使用者旅程和 視覺設計。因此，可以用其他技術來補充使用者故事，例如故事地圖，工作流程圖，故事板，草圖和模型。

另外，使用者故事不能很好地捕捉技術要求。如果您需要傳達像元件或服務這樣的架構元素應該做什麼，那麼請編寫技術故事，或者，根據我的偏好——使用像UML這樣的建模語言。

最後，在開發可能被重用的軟體時，編寫使用者故事是值得的。但是，如果你想快速建立一個一次性原型或模型來驗證一個想法，那麼寫故事可能不是必要的。記住：使用者故事不是關於記錄需求; 他們希望能夠使您更快並儘快開發軟體，而不是強加額外的開銷。