用戶故事是敏捷團隊中捕捉功能願望的事實上的標準。用戶故事通常是從最終用戶或系統用戶的角度編寫的。換句話說，用戶故事描述了用戶的類型、他們想要什麼以及為什麼。用戶故事有助於創建需求的簡化描述。根據項目的不同，用戶故事可能由不同的利益相關者編寫，包括客戶、用戶、經理或開發團隊成員。
用戶故事模板：角色-行動-收益
用戶故事僅捕獲需求的基本要素。格式為“作為<誰>我想要<什麼>以便<受益>”：
角色 (Role)- 用戶應該是與系統交互的實際人。
- 要盡可能具體
- 開發團隊不是用戶
動作 (Action) ——系統的行為應該寫成一個動作。
- 通常每個用戶故事都是獨一無二的
- “系統”是隱含的，並沒有寫在故事中
- 主動語態，而不是被動語態（“我可以得到通知”）
好處 (Benefit) ——好處應該是一個現實世界的結果，它是非功能性的或系統外部的。
- 許多故事可能共享相同的利益聲明。
- 好處可能是其他用戶或客戶的，而不僅僅是故事中的用戶。
筆記：
用戶故事是用日常語言編寫的，從個人（誰）的角度描述一個特定的目標（什麼）以及他/她想要它的原因（為什麼）。
用戶故事示例
- 作為<招聘人員>我可以<發布新工作>以便<求職者可以通過搜索找到這些工作>
- 作為<求職者>我可以<限制誰看到我的簡歷>這樣<我有隱私>
用戶故事的 3 C（卡片 Card、對話 Conversation、確認 Confirmation）
卡片——用於計劃和估算的故事的書面描述。
對話– 與他人討論您的想法。讓他們問很多問題。共同努力提出理想的解決方案。目標是建立共識。
確認——努力就構建內容達成一致。將該協議記錄為一組確認測試。
不良用戶故事示例
- 該軟件是用C++編寫的
- 數據庫 (database) 會有一個連接池 (connection pool)
如何使用 INVEST 指南編寫好的用戶故事
首字母縮略詞 INVEST 有助於記住一組廣泛接受的標准或清單，以評估用戶故事的質量。如果故事不符合這些標準之一，團隊可能想要改寫它，甚至考慮重寫（這通常轉化為物理撕毀舊故事卡並編寫新故事卡）。
獨立 (Independent) ——每個用戶故事都應該代表一組獨特且獨立的業務價值，這樣，如果它自己發布，它將比以前的狀態提供增量價值。
可商議 (Negotiable)-雖然最終目標可明確說明，通過這項目標的實現方法應該是流通-產品負責人及開發團隊，產品負責人與客戶，或任何其他各利益相關者之間-以防止對特性或功能的不切實際的限制。
有價值 (Valuable) ——通過閱讀故事，任何用戶故事的商業價值都應該很容易識別，每個故事都應該代表特定用戶類型的某種價值。
可估量 (Estimable) ——我們必須有足夠的信息來適當地調整故事的大小，以便我們可以適當地計劃並致力於我們的工作。（但沒有了！）
小的 (Small)——用戶故事應該足夠小，以便它們能夠在衝刺中完成。
可測試 (Testable) ——團隊的所有成員都需要一種清晰準確的方法來驗證用戶故事是否已完成。
注意：
INVEST是用於快速評估用戶故事質量的指南，源自 Bill Wake 的一篇文章，該文章還將首字母縮略詞SMART（特定、可衡量、可實現、相關、限時）重新用於用戶故事技術分解所產生的任務。
Scrum and User Story Articles:
