「作為消費者，我希望保存我的支付方式，以便下次結帳更快。」 這就是一個用戶故事。它是一個句子，而不是一個規範。敏捷軟體團隊通常會將使用者故事寫在索引卡片或便條紙上。這種格式要求編寫者明確角色、目標和原因。它確保關注點始終放在實際使用該功能的人身上，而不是資料庫模式。

使用者故事由 Kent Beck 和 Ron Jeffries 在 20 世紀 90 年代末推廣開來。它們故意設計得不完整。使用者故事卡象徵著一次對話的承諾。開發人員、設計師和產品經理會共同探討細節。驗收標準會在之後再增加。過於龐大的故事稱為史詩級故事。過於模糊的故事則可能成為潛在的 bug。

三個C

• Card: 文字故事，篇幅短小，足以寫在紙上。
• Conversation: 填補空白的討論。
• 確認：證明其有效性的測試。

好的使用者故事是獨立的、可協商的、有價值的、可評估的、簡潔的、可測試的。它的首字母縮寫是 INVEST。這並非教條。有些團隊把使用者故事寫成工作故事：「當我遲到時，我希望能夠一鍵支付，這樣我就不會錯過火車。」想法相同，框架不同。