用户故事是什么：
用户故事是可用于陈述业务价值的一种简便格式，适用于各种PBI，特别是特性。
如何描述用户故事要遵循3C原则，即：卡片card， 会话conversation， 确认confirmation。
1、卡片要写明用户种类（即用户角色Who）、这类用户想要达成什么（目标What）以及用户为什么想达成此目标（收益Why）。使用卡片是为了简洁，并提醒干系人进行更深入的讨论。
2、会话开启了一个更加丰富的信息交易与协作形式。从而确保正确描述需求并使每个人都能理解需求。
3、确认则提现为满意条件的形式，更加有利于构建和测试。
好的用户故事：
BillWake给出了6大标准即INVEST。
独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimatable）、?。⊿mall）、可测试（Test）。
下面逐一讲解各个标准的含义：
独立：用户故事是独立的，至少应是松耦合。因为依赖程度过高会使得估算、排序规划都比较复杂。
可协商：故事和普通瀑布模型需求不同，是可以协商的。
有价值：故事有价值，客户才会支付产品。当然对于技术性故事属于完成因为价值所涉及的任务。
可估算：指的是故事的故事的工作量和成本。如果团队无法衡量故事大小，原因不外乎两个：故事太大或太模糊；团队积累的知识不够。
大小合适：刚才提到的用户故事四个层级抽象，一定要够小，同时一定要考虑故事的时间点。
可测试：故事要么测试通过要么测试失败，测试标准就是3C中的确认。
如何收集用户故事：
用户故事研讨会、绘制故事地图是两种比较有效的方法。
用户故事研讨会：可以集中进行头脑风暴，讨论预期的业务价值，并为目标产品和服务创建用户故事占位符。
绘制故事地图：将概要性用户活动分解为工作流，工作流还可以继续分解为一套明确的任务。如下图所示，横轴为工作流（使用顺序）纵轴为优先顺序。它结合了用户为中心和故事分解这两大概念。
用户故事的局限：
创造出色的用户体验（UX）需要的不仅仅是用户故事。用户故事有助于捕捉产品功能，但不能很好地描述用户旅程和视觉设计。因此，可以用其他技术来补充用户故事，例如故事地图，工作流程图，故事板，草图和模型。
另外，用户故事不能很好地捕捉技术要求。如果您需要传达像组件或服务这样的架构元素应该做什么，那么请编写技术故事，或者，根据我的偏好——使用像UML这样的建模语言。
