用户故事地图 - Agile307/agile GitHub Wiki
用户故事地图，提供了2维的角度来分析用户故事，直观，更加有利于优先级的表达。 在理解用户故事地图时，需要注意其作者的用词跟一般的用户故事不一致，因此要注意跟普通的用户故事用词之间的对应关系。 推荐一般理解如下：
- 一幅用户故事地图展现1个史诗Epic
- User Acitivites(Backbone)行，可以理解为对史诗Epic的一级功能分解
- User Tasks(Walking Skeleton）行，可以理解为对史诗Epic的二级功能分解。这里千万注意，这与一般用户故事的任务完全不是一回事，里面的条目是表明了一个功能方向，比如搜索Email。
虽然用户故事地图解决了不少故事分析的困难，但用户故事地图方法仍然有缺点，主要缺点分析如下。
-
无法表现多分支流程
User Activities(Backbone)是自左向右的单线，当流程复杂有分支时，只能横向单行排列 -
无法表现多个用户参与的互动
User Storis的展现是不能区分多个用户参与，需要通过故事本身的标题来区分，不直观
以上2个缺点在普通的Backlog中一样存在，但普通的Backlog以优先级排序为其最核心作用，没有更高的期望。而用户故事地图采用了二维图形展示，那么很容易对它产生以上的期望，进而把以上两点看作是缺陷。
-
需要额外专门的工具来存储地图
地图的纵向跨越了多个迭代，不是所有的团队能有一块大板长期存放故事地图，就算是有一块大板，随着时间推移，也不可能足够的大板来存储所有的地图，所以必然要借助于电子化工具，比如Excel、Word。可惜Excel和Word不支持团队线上协作，但当前常见的团队线上协作工具并不支持故事地图功能，而为了支持故事地图，业界出现了支持故事地图的专门工具。 -
对于没有预估到的故事，后续识别后需要调整地图
世界变化快，迭代之间甚至迭代之内都有可能出现需求变化，需要调整用户故事，比如迭代之内实施选定用户故事时，随着编码得到更多的澄清，发现需要分拆用户故事；迭代末进行演示之后，收到了快速反馈，需要调整某些个用户故事，这些情况都将导致用户故事地图的调整，而这些情况是经常发生的。