“作为消费者，我希望保存我的支付方式，以便下次结账更快。” 这就是一个用户故事。它是一个句子，而不是一份规范。敏捷软件团队通常将用户故事写在索引卡片或便签纸上。这种格式要求编写者明确角色、目标和原因。它确保关注点始终放在实际使用该功能的人身上，而不是数据库模式上。

用户故事由 Kent Beck 和 Ron Jeffries 在 20 世纪 90 年代末推广开来。它们故意设计得不完整。用户故事卡片象征着一次对话的承诺。开发人员、设计师和产品经理会共同探讨细节。验收标准会在之后添加。过于庞大的故事被称为史诗级故事。过于模糊的故事则可能成为潜在的 bug。

三个C

• Card: 文字故事，篇幅短小，足以写在纸上。
• Conversation: 填补空白的讨论。
• 确认：证明其有效性的测试。

好的用户故事是独立的、可协商的、有价值的、可评估的、简洁的、可测试的。它的首字母缩写是 INVEST。这并非教条。有些团队把用户故事写成工作故事：“当我迟到时，我希望能够一键支付，这样我就不会错过火车。” 想法相同，框架不同。