使用者故事（英語：User story）是指從使用者的視角來表達軟體需求的一種方式

使用者故事不能夠使用技術語言來描述，要使用使用者可以理解的業務語言來描述。使用者故事可以幫助研發團隊理解真正的使用者需求是什麼，也可以促進業務人員和研發團隊的溝通和協作。

一個好的使用者故事包括三個要素：

1.     角色：誰要使用這個功能。

2.     活動：需要完成什麼樣的功能。

3.     商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。

使用者故事通常按照如下的格式來表達：

英文：

As a <Role>, I want to <Activity>, so that <Business Value>.    

中文：

作為一個<角色>, 我想要<活動>, 以便於<商業價值>

關於一則使用者故事是否完整，我經常用一套標準來衡量。這套標準是比爾·韋克（Bill Wake）發明的。他認為，一個好的使用者故事應該滿足INVEST 原則：

• 獨立性（Independent）—   要儘可能的讓一個使用者故事獨立於其他的使用者故事。使用者故事之間的依賴使得制定計劃，確定優先順序，工作量估算都變得很困難。通常我們可以通過組合使用者故事和分解使用者故事來減少依賴性。
• 可協商性（Negotiable）—  一個使用者故事的內容要是可以協商的，使用者故事不是合同。一個使用者故事卡片上只是對使用者故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個使用者故事卡帶有了太多的細節，實際上限制了和使用者的溝通。
• 有價值（Valuable）— 每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。
• 可以估算性（Estimable）—開發團隊需要去估計一個使用者故事以便確定優先順序，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
• 短小（Small）— 一個好的故事在工作量上要儘量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。使用者故事越大，在安排計劃，工作量估算等方面的風險就會越大。
• 可測試性（Testable）—一個使用者故事要是可以測試的，以便於確認它是可以完成的。如果一個使用者故事不能夠測試，那麼你就無法知道它什麼時候可以完成。一個不可測試的使用者故事例子：軟體應該是易於使用的。

關於使用者故事，Ron Jeffries用3個C來描述它：

卡片（Card） – 使用者故事一般寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工作量估算等。

交談（Conversation）- 使用者故事背後的細節來源於和客戶或者產品負責人的交流溝通。

確認（Confirmation）- 通過驗收測試確認使用者故事被正確完成。

那麼 我們怎麼用Leangoo看板來管理使用者故事呢？

• 卡片

在Leangoo中，使用者故事體現為一張卡片，卡片的標題通常就是使用者故事的一句話描述。

• 交談

開發團隊可以圍繞使用者故事展開討論，討論的細節可以放在卡片的描述裡面，所有跟故事相關的詳細的資訊，比如業務邏輯，頁面原型的設計，規則等等這些內容都可以放在卡片的描述裡面。

Leangoo的卡片描述支援圖文結構。

• 確認

每個使用者故事都會驗收條件，驗收條件在Leangoo中可以用檢查項來表達。

在敏捷裡面，使用者故事通常放在產品backlog裡 ，我們會建立一個產品backlog看板，把這些使用者故事放在產品backlog裡面