用戶故事是從用戶的角度來描述用戶渴望得到的功能。

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

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

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

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

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

英文：

As a ‘Role’， I want to ‘Activity’， so that ‘Business Value’

中文：

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

舉例：

作為一個“網站管理員”，我想要“統計每天有多少人訪問了我的網站”，以便于“我的贊助商了解我的網站會給他們帶來什么收益。”

需要注意的是用戶故事不能夠使用技術語言來描述，要使用用戶可以理解的業務語言來描述。

Ron Jeffries的3個C

關于用戶故事，Ron Jeffries用3個C來描述它：

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

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

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

用戶故事的六個特性 INVEST

INVEST = Independent，Negotiable，Valuable，Estimable，Small，Testable

一個好的用戶故事應該遵循INVEST原則。

• 獨立性（Independent）

  要盡可能的讓一個用戶故事獨立于其他的用戶故事。用戶故事之間的依賴使得制定計劃，確定優先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。

• 可協商性（Negotiable）

  一個用戶故事的內容要是可以協商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。

• 有價值（Valuable）

  每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

• 可以估算性（Estimable）

  開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計劃。但是讓開發者難以估計故事的問題來自：對于領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

• 短小（Small）

  一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。用戶故事越大，在安排計劃，工作量估算等方面的風險就會越大。

• 可測試性（Testable）

  一個用戶故事要是可以測試的，以便于確認它是可以完成的。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。一個不可測試的用戶故事例子：軟件應該是易于使用的。