为什么会有用户故事地图？

迭代开始后，待办列表总是以小块形式进入迭代开发，一个迭代接着一个迭代。碎片化的方式，不能给产品以及开发团队一个整体的视觉。这会出现，优先级排列问题，或者产生多个迭代后，用户还是看不到用户想要的东西的雏形。

用户故事地图，就是一堵Story墙，大级别的用户故事排在头排，根据优先级，描述用户需求。对每个头排用户故事成纵向分解。通过地图方式，可以让你和同事能够有一个空间充分思考各类可行方案，从而找到一条可以最大化投入产出的路子。可以让各种干系人对功能需求有相对一致的理解和整体认识。

回顾一下PO如何用3C原则和开发团队队一起精炼用户需求（Product Backlog Refinement）

  a. 【Card】PO写User Story， User  Story用户故事的格式常用 作为一个【用户】，我想【做什么】，这样我就可以【什么什么】

     PO和客户交流的时候，不要直接问用户要什么，要知道用户背后的原因，和用户一起找出用户真正想要的功能。在用户故事一书中，做蛋糕的师傅问，蛋糕给谁，她有什么喜好，多少人吃。并没有直接问尺寸多大，蛋糕师傅可以帮客户确认多大蛋糕合适。也没有问需要在蛋糕上做些什么花样，而是问有什么喜好，蛋糕师傅更加专业，可以给客户更好的选择和惊喜。

  b. 【Conversation】PO和团队交谈讨论用户故事，确保理解一致

  c. 【Confirmation】团队写出Acceptance Criteria, AC是对PB的细化。PB陈述了用户要什么，AC陈述了用户怎么做到。比如一个PB是需要登录页面，AC可以是用户通过登录页面，输入正确的账号和密码，页面显示登录成功。一个PB经常对于多个AC，比如密码出错的情况，也是一种AC。AC写了，由PO确认。但不签字（签字就以为这一种合约，合约意味着签合约双方代表不同利益，但是实质上PO和团队是在一个scrum team）。

    整个精炼用户需求PBR过程，不在Sprint里完成。是一个长期存在的活动，上一个sprint里就需要把下一个sprint的需求精炼细化。建议利用碎片时间完成。