一、用户故事，敏捷环境
将所有的需求拆解成用户故事，从用户角度对系统的某个功能模块所做的简短描述（需求文档刚好相反，关注的是系统功能，很少会提及用户场景）。一个好的用户故事包括三个要素：
角色：谁要使用这个功能，
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能能带来什么样的价值。
例：
作为信用卡客户Jack
希望可以从取款机中用信用卡取现金
这样能够购买只能用现金购买的商品
二、验收条件（Acceptance Criteria）
在对齐用户故事的过程中，我们可以通过上图的方向进行思考和提问，以达到澄清需求的目标。至于用户故事的最终呈现形式，并不是那么的重要。
三、用户故事地图
如上图，用户故事地图，就是一堵用户故事墙，大级别的用户故事排在第一列，根据优先级，描述用户需求。对第一排故事成纵向分解。通过地图方式，可以让团队能够有一个空间充分思考各类可行方案，从而找到一条可以最大化投入产出的路子。可以让各种干系人对功能需求有相对一致的理解和整体认识。同时，根据这些故事排列出每个迭代的用户故事优先级。
用户故事地图还可以传送出很多的信息，比如它的橫纵坐标，其实是非常有意义的，横轴代表了用户的使用路线图，纵轴代表了需求的优先级。那几条红色的虚线，就代表了每个迭代需要做的基本内容了，相当于一个粗粒度的迭代待办列表（Sprint Back log）。
注意：这个地图是动态变化的。每经过一段时间，团队都应该重新审视这张用户故事地图，看看我们的规划是否发生了偏差？还有哪些需要补充的？有没有更好的意见或者建议？是否有些功能是不必要的？
四、实例分享
内部关于需求的管理方式，基于Confluence工具，模板如下图：
通过下面这个文档，我们可以很清晰的知道用户故事的信息：在哪个迭代被研发，需求内容是什么，如何去做验收。
·需求说明
·工作流程
（泳道图/交互图等）
·验收条件
GIVEN WHEN THEN REMARK
·原型/UI设计
五、延伸：用户故事的六个特性
好的用户故事满足INVEST原则
Independent 独立性
Negotiable 可协商
Valuable 有价值
Estimable 可估算
Small 足够小
Testable 可测试性
独立性：要尽可能地让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性：一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值：每个故事必须对客户具有价值（无论是用户还是购买方）。
可以估算性：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。通常让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小：一个好的故事在工作量上要尽量短小，最好不要超过3天的工作量（我们的实践，具体可根据团队自行定义），用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性：一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那你就无法知道它什么时候可以完成。
六、小结
在需求评审的阶段，从用户使用场景的角度出发，通过提问，把需求逐步澄清，并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。根据用户故事的基本特性，做到业务可验收、研发可实现、测试可验证、部署可交付。
