用户故事地图，个人的理解有四大作用：
一、解决“只见树木不见森林”的问题，产品全景可视化还是非常有必要的。
二、所有相关干系人达到需求上的共识，特别在流程和价值认可上。一定要拉上产品负责人，业务，开发骨干，测试骨干一起进行梳理用户故事地图，特别是得到业务的想法和认同。从客户价值维度分析需求优先级，管理客户期望值降低交付风险，正是用户故事地图的魅力体现。
三、形成MVP以及迭代计划，为后面的需求梳理、澄清，迭代实现做好了铺垫。自左往右是进行流程梳理；从上往下是故事价值由高到低，这样排在最上面的故事很自然就会形成MVP，后面根据优先级，按照“正好-更好-最好”的原则进行迭代划分，从而形成了初期的迭代计划。书中对MVP的定义非常认可：MVP最小可行产品是为验证假设而做的最小规模的实验。
四、还可间接地进行可视化项目进展跟踪。可以在故事地图上标注可交付的故事（比如打勾），剩下的就是未交付的故事，大致能看到还有多少故事未完成。
目前最大的问题是业务部门实际上是没参与到用户故事地图的探讨中，且还没有具备敏捷迭代的思维以及没有体会到价值持续交付的甜头。大环境的改变非常困难，也需要非常漫长的时间。我们自己团队内部在项目初期进行了用户故事地图的梳理会议，但后面并没有对其进行跟进完善更新（由于场地的限制）没有完全利用好用户故事地图，仅wiki里有电子版的用户故事地图更新维护。
关于用户故事，很多freshers最困惑的问题就是怎样的故事才是好故事，故事的规模到底该怎么定义。我简单的认为：能在迭代周期能完成且团队都认可的故事就是好故事，没有恒定的标准。故事主要是靠讲的，核心是重视相关干系人的沟通协作让所有人达到故事理解的一致，用户故事之所以得名，并不是要人们如何写出更好的用户故事，而是如何在协作中更好地使用它。用户故事遵守3C和3W原则即可。（3C原则：卡片Card，在一堆卡片上写下你期望的软件特性；交谈Conversation，聚在一起对要开发的软件进行深入讨论；确认Confirmation，对完工条件进行确认。3W：用户角色who，功能what，为什么why。作为[一个用户]，我想要[某个产品特性]，这样我就可以[获得某种收益]。）
一期划分故事基本都是按史诗级故事划分，虽然少但还是能在当时制定的迭代周期（一个月）里完成；二期由于迭代周期缩短（两周），大故事被拆分小故事，故事显得较多，但也是完美适应迭代周期的。2种故事划分方法都不存在谁优谁劣。
做的比较好的地方是在项目尚未启动，就已经优先做了高保真原型，并拿出去和业务部门进行了沟通，得到了业务部门的认可。
总之，用户故事地图作为一种有效的需求工具，越来越广泛地应用于开发实践中。
