。在用户故事地图中，这三层被分别叫做用户行为User Activity，用户任务User Task，用户故事User Story（注：也有些图形中称之为子任务Sub-task）。
中间蓝色的线条，则把所有功能分为若干个Release发布（可以认为是传统的迭代或冲刺Sprint）；而当前发布，也就是Release 1中需求的状态，则被几个小纸片（WIP=Work In Progress开发中，Done=完成）标识。
用户故事地图的最大的贡献，不是引入了三个新的令人困惑的层级，而是把时间引入到需求的空间结构中。这种革命，无异于在二十世纪初期，爱因斯坦告诉人们宇宙是由三维空间和一维时间组成的。
为何故事嫁时间？
为何在这么多用户故事结构中，唯独用户故事地图脱颖而出呢？因为在用户故事地图中，故事嫁给了时间。
在敏捷开发中，用户故事不是一次性开发出来的，而是在不同的迭代中进行开发，因此用户故事的最重要的属性，就是需要与时间相关。否则人们在用户故事之外，就要额外地做一个迭代计划。
因而，用户故事地图中并存的空间（故事之间的分层关系）和时间（故事发布的顺序）两个维度，非常好地解决了敏捷开发的这个需求。
用户故事地图 vs. 看板
但是早在用户故事地图出现之前就已经有看板了，而且看板中也有时间的维度，那么两者的区别到底是什么呢？
看板中只管理一个迭代中的内容，看板上的故事或任务之间的关联关系也比较弱（这不等于没有实质关联关系，只是看板上没有办法管理），而分层关系则完全没有。
如果产品规模很小，不太需要长期的计划，那么看板足以胜任。但是如果产品规模大周期长，就需要对多个迭代的看板进行管理，这个看板就做不到了。
而用户故事地图则可以同时看到多个迭代、完整产品需求的状态。
换个角度，看板适合项目经理，用户故事地图适合产品经理。
为什么是现在？
实际上，所有东西的出现都不是偶然的。
在早期使用软件工具的，都是大型公司和大型团队，而且他们会更倾向于使用瀑布模型，因此才会出现类似树形的庞大的需求管理方法。即使后来这些工具转而支持敏捷开发，时间轴始终没有被加进去，或者虽然被加进去，但是却被置于次要地位。
后来小型团队里也开始尝试使用敏捷开发，但是对于小型团队而言，看板已经足够了。
再往后则是使用敏捷开发的小型团队逐渐开始成长，人们逐渐意识到，对于跨迭代的大量需求的管理是一个关键因素，这时候就催生了用户故事地图。
用户故事地图是大型、长周期产品开始使用敏捷开发的产物。
但如果换作开发角色来分析，则会发现另外一个有趣的趋势。
最早出现的敏捷分支是XP，同期火热的方法论还有面向对象OO、统一建模语言UML。
这是一个技术主导开发的时代。
后来出现的敏捷分支则是Scrum和看板Kanban。Scrum在技术之外扩展了很多领域，但整体上限于计划和跟踪；看板则聚焦于任务安排和资源调配。
这一时期的方法论基本无视产品需求的收集分析以及产品最终的发布，因为当时世界上主要以项目开发型的公司为主，产品及需求相关的事情均由客户或者其他团队负责。
同一时期出现的CMMI虽然包含了很多需求分析、管理、验收的内容，但都是在甲乙方外包的场景中描述的。
进度、质量、成本这个铁三角被大家挂在嘴上，产品、需求、发布长期缺席。
这是一个项目管理主导开发的时代。
最近出现的则是用户故事地图和DevOps。前者帮助产品经理分析和规划需求，后者帮助产品经理将开发中的产品
