參考
極限程式設計引入了使用者故事的形式來表達需求，它是功能的簡短描述，對軟體使用者和客戶都很有價值。下面是乙個典型的使用者故事（工作發布和搜尋站點）：
但是使用者故事不僅僅只是這些文字小片段。各個使用者故事包含三個方面：
故事的描述，用於計畫和作為乙個提醒
詳談故事，以使故事細節具體化
測試，確認故事已經完成
為什麼使用故事
因為故事展示出用例或者傳統需求方法的一些相同特徵，故事區別於這些早期的需求技術就變得非常重要。這些差異使得故事具有很多的優勢：
使用者故事強調口頭交流。字面語言經常是含糊的，無法保證客戶和開發者以相同的方式理解。有時我們認為文字是準確的，但是實際上不是。
對計畫有益
故事的另乙個益處是使專案計畫能夠被容易的使用。每個使用者故事都進行了困難程度和時間上的估計。另一方面，用例通常太大以致於難以給出有用的估計。故事一般在
敏捷專案中的單個迭代實現，而用例一般會分成若干次迭代。
使用者故事鼓勵延遲收集詳細
乙個初始化的目標級的故事，可以被更加詳細的多個故事替代。
使用者故事不是用例
使用者故事與用例最明顯的差異就是範圍。兩個都用來傳遞商業價值，但是我們限定故事的大小，例如不超過10天的開發周期，以便用於開發計畫。
使用者故事與用例的另一區別是完成的級別。故事相當於用例成功的場景，故事測試相當於用例擴充套件。
還有乙個區別是用例和故事存在的時間，用例 是長期工件。故事通常只在故事迭代中存在。
用例更傾向於包含使用者介面的細節。有幾個原因，用例導致大量的文件，以致沒有其它地方來放介面需求。用例更早關注軟體實現而不是商業目標。
來自 在最近的諮詢過程中，經常有客戶問到「使用者故事和用例是什麼關係？」、「使用者故事是不是取代了用例？」、「什麼時候用用例、什麼時候用使用者故事？」、「特性和用例是什麼關係？」。以下把我的想法整理了一下，首先先駁斥一些觀點吧：
錯誤觀點１：使用者故事會取代用例；
如ｍａｒｔｉｎ在他的部落格中所說的，使用者故事和用例都是組織需求的方式，只是目的不同而已，用例的目的是為了把需求描述清楚，而使用者故事的目的是把需求分解成可用於迭代計畫的單元（
錯誤觀點２：用例是不敏捷的；
其實，在寫作用例的過程中，使用者也可以根據需要將用例寫到不同的詳細程度（如概要級），所以，用例技術也是可以用到敏捷專案中的；
那麼用例和使用者故事是什麼關係呢？或者說如何從用例匯出使用者故事呢？用例是許多個（可能是幾百個）場景的抽象；用例是用基本流和備選流組合的方式來高效地描述這些場景（可能有幾十個流），所以乙個流可能對應多個場景（如在下圖中備選流１就對應了場景ｂ和ｄ），而場景實際上是流的排列。
使用者故事會包含乙個或多個場景，也可能是乙個場景的某些步驟，所以應該說在大多數情況下，乙個用例會包含許多個使用者故事。
在ｉｊｉ的方**當中，我們引入了另外乙個概念叫用例模組，用例模組對應乙個或幾個流所代表的場景（功能需求）以及相關的非功能需求，用例模組還應該包含驗證上述需求的測試用例。使用者故事和用例模組基本上是在乙個抽象層次的，或者是，用例模組是一種從用例分解到使用者故事的方式。
敏捷讀書之使用者故事 《使用者故事與敏捷方法》解讀
本期分享mike cohn 使用者故事與敏捷方法 精益思想五步 價值，價值流，流動，拉動，盡善盡美。使用者故事是精益思想五步的核心載體。首先，使用者故事是價值載體，是承載使用者價值的基本單元。使用者故事要承載價值，而價值也要承載在使用者故事這種歸一化的載體中。其次，使用者故事是節拍器。故事有節奏的流...
使用者故事1
us1 新使用者註冊 新使用者 軟體引導頁面之後點進入 頁面顯示登入註冊 點選註冊 填寫基本資訊 完成註冊 已註冊使用者 輸入賬戶密碼登入 完善資料 us2 客房檢視 已註冊使用者 進入軟體首頁 頁面顯示客房型別 標準間 大床房 雙床房 鐘點房 點選房型檢視客房詳細資訊 管理員 後台登入 瀏覽客房 ...
13 使用者故事與敏捷方法 使用者故事的優勢筆記
00.使用者故事好處 a.使用者故事強調口頭溝通 b.人人都可以理解使用者故事 c.使用者故事的大小適合做計畫 d.使用者故事適合於迭代開發 e.使用者故事鼓勵延遲細節 f.使用者故事支援隨機應變的開發 g.使用者故事鼓勵參與性設計 h.使用者故事傳播隱性的知識 01.在嘗試之前，你或者會天真地以為...