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

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

舉例：

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

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

使用者故事來描述產品需求是敏捷開發實踐必須學習和轉變的第一項工作，最經典的三段論，“作為一個…(角色)，可以<能夠>…(功能)，以便…(客戶價值)，這個語法很好地表明瞭需求的三個最重要的要素：角色，功能，客戶價值。

　　為什麼需要角色，

　　1. 有利於特定的使用者核實，有一個“角色“欄位，都令溝通工作可以與適當的角色進行，完成的產品自然也就令這些角色的人員滿意。

　　2. 有利於開發人員理解場景，角色與“普通使用者/管理員/執行人“這些區別，可以使開發人員更容易理解產品的使用者，風格、操作人員的熟練程度、操作習慣。

功能描述最好遵從以下兩條規則

　　1. 主語-謂語原則

　　比如，作為一個會議系統管理員，可以顯示所有使用者的提問，以便。。。。

　　是不是彆扭，對可以轉換成“可以檢視所有使用者的提問“，這樣是通過角色+謂語的方式來描述

　　2. 動賓片語原則

　在功能動作描述的時候，儘量採用動詞+賓語的描述，如新建使用者，檢視所有評論等。

　　所以對於功能的描述應該是： 把角色作為主語，功能主題的描述採用動賓結構。

　　使用者價值

　　使用者價值看似很簡單，但是其實是很難寫，而且很重要。

　　如：作為會議管理員，可以檢視所有使用者的提問，以便了解哪些使用者發表的評論。看上去這種價值描述不錯。但是如果系統只是為了檢視的話，會議管理員為什麼要檢視?如果評論很多，他如何檢視?

　　所以使用者故事的價值描述，給需求分析做了一些價值挖掘的要求，團隊要去挖掘角色做這一動作的價值，要為角色挖掘出必要且合理的理由。

　　使用者故事作為需求分析和研發的依據，是在敏捷開發實踐過程中首先需要去實踐的一個重要環節，看似簡單的使用者故事，在實際操作中是相對困難的，如何從傳統的功能描述轉變成客戶和研發團隊都能理解的使用者，這裡有很多技巧。包括如何確定角色，使用者故事顆粒度，使用者故事的評估等問題。

推薦大家一本書科恩(美)的《使用者故事與敏捷方法》。