用户故事（英语：User story）是指从用户的视角来表达软件需求的一种方式
用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。用户故事可以帮助研发团队理解真正的用户需求是什么，也可以促进业务人员和研发团队的沟通和协作。
一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
关于一则用户故事是否完整，我经常用一套标准来衡量。这套标准是比尔·韦克（Bill Wake）发明的。他认为，一个好的用户故事应该满足INVEST 原则：
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
那么 我们怎么用Leangoo看板来管理用户故事呢？
卡片
在Leangoo中，用户故事体现为一张卡片，卡片的标题通常就是用户故事的一句话描述。
交谈
开发团队可以围绕用户故事展开讨论，讨论的细节可以放在卡片的描述里面，所有跟故事相关的详细的信息，比如业务逻辑，页面原型的设计，规则等等这些内容都可以放在卡片的描述里面。
Leangoo的卡片描述支持图文结构。
确认
每个用户故事都会验收条件，验收条件在Leangoo中可以用检查项来表达。
在敏捷里面，用户故事通常放在产品backlog里 ，我们会创建一个产品backlog看板，把这些用户故事放在产品backlog里面
