使用者故事描述了對軟體（或系統）使用者或客戶有價值的功能。使用者故事包括三方面內容：書面描述（用於計畫和備忘），交談（細化故事細節），以及測試用例（驗證故事實現）。使用者故事描述的傳統形式是手工書寫的使用者故事卡，
ron jeffries
稱如上三方面內容為
card(卡片)
、conversation(交談)
和confirmation(
確認)。
使用者故事一般包括3方面的要求：作為（系統的乙個涉眾），我想要（做一件事），從而（達到乙個商業價值）。比如倉庫管理中有這樣乙個想法：倉庫操作人員想通過使用手持裝置完成倉庫的揀選商品的操作，以提公升倉庫工作人員的工作效率。其中受眾是倉庫操作人員，業務操作是使用手持裝置進行商品的揀選，目的是提公升倉庫操作人員的效率，實現商業目標。
開發者輔助客戶編寫故事，告訴客戶所編寫的故事是進一步討論的引子，而不是詳細的需求規範。在任何專案中，需要客戶團隊根據故事的重要性來安排開發者的工作，回答所有開發者的問題，編寫所有的故事。客戶團隊包含多個成員（諸如測試人員、產品經理、真實使用者、互動功能設計人員），確保軟體滿足目標使用者的需求。
在編寫故事之前應該建立使用者角色模型，必須包含對專案成功至關重要的角色，盡量保證所有使用者對系統完全滿意。
如想建立優秀的故事，需要認真領會
6個屬性，分別是：獨立性、可協商性、對使用者或者客戶有價值、可**性、短小精悍，以及可測試性。
bill wake
使用縮寫詞
invest表示6
個屬性:
1）獨立性。盡可能避免故事之間存在依賴關係，故事間依賴關係會產生優先順序和規劃問題。
2）可協商性。故事是可協商的，不是必須實現的書面合同或者需求。
3）對使用者或者客戶有價值。確保每個故事對客戶或使用者有價值的最好方式是讓使用者編寫故事。
4）可**性。開發者應該能夠**（至少大致猜測）故事的規模，以及編碼實現所需要的時間。
5）短小精悍。故事規模對實現有影響，何種故事規模最合適，取決於開發組規模、開發組的能力，以及技術實現等方面。
6）測試性。所編寫的故事必須是可測試的。
與用例的區別
用例最早由
ivar jacobson
在1992
年提出，用例通常與統一軟體過程相聯絡。用例描述系統和角色之間的互動。兩者差別主要在於： 1
）範圍不同。二者都用來體現商業價值，但故事規模可以設定比較小（例如，
10天完成），以便以此為單位安排工作。用例包含的範圍可能比故事大得多。
2）完成程度不同。
james grenning
曾指出：故事卡中的文字「加上驗收測試用例就基本等同於用例」，這意味著故事對應於用例的基本流，而故事的測試要求對應於用例的備選流。
3）壽命不同。用例通常是持久的工作產品，在產品開發和維護時，用例一直存在。然而，故事通常只存在於實現該故事的迭代中。雖然故事卡可以存檔，但是許多團隊都將故事卡銷毀。
4）編寫目的不同。用例的目的是記錄客戶和開發團隊的一致意見。故事是為了便於制定發布計畫和迭代計畫，並作為有關使用者需求細節方面的交談備忘錄。
這裡我們將選擇使用者故事來驅動後續工作的進行。
使用者故事 vs 用例
使用者故事與用例是一回事嗎？人們經常會問這個問題，關於敏捷團隊是否應該練習使用故事與使用案例的糾紛已經存在多年。使用者故事和用例是一樣的嗎？如果沒有，哪個更好？你應該使用哪乙個？或者可以同時使用？雖然使用者故事和用例之間存在一些相似之處，但使用者故事和用例不可互換 使用者故事和用例都標識使用者，他們...
使用者故事與用例
使用者故事與用例是一回事嗎？人們經常會問這個問題，關於敏捷團隊是否應該練習使用故事與使用案例的糾紛已經存在多年。使用者故事和用例是一樣的嗎？如果沒有，哪個更好？你應該使用哪乙個？或者可以同時使用？雖然使用者故事和用例之間存在一些相似之處，但使用者故事和用例不可互換 使用者故事和用例都標識使用者，他們...
1 敏捷 使用者故事的好處
參考 極限程式設計引入了使用者故事的形式來表達需求，它是功能的簡短描述，對軟體使用者和客戶都很有價值。下面是乙個典型的使用者故事 工作發布和搜尋站點 但是使用者故事不僅僅只是這些文字小片段。各個使用者故事包含三個方面 故事的描述，用於計畫和作為乙個提醒 詳談故事，以使故事細節具體化 測試，確認故事已...