为什么扁平的用户故事待办列表效果不好？如何构建一个更好的用户故事待办列表，用来更有效的描述你的系统，进行优先级排序和制定发布计划。
这是Gary。
Gary和我用了一整天的时间制作了一副用户故事地图——一个更好的产品待办列表。构建用户故事地图帮助我们聚焦在产品的全貌上而不是关注每一个用户故事。
当进行优先级排序时，Gary基于整个系统的上下文进行排序。Gary的目标是构建一个叫做Mimi (Music Industry Marketing Interface 一个面向音乐行业的系统) 的产品。然而，当对“乐队成员宣传音乐会”这个故事进行排序时，发现这个故事太大了，事实上这应该是一个“史诗故事”，后来它占据了地图上的很大面积去考虑所有的细节，比如：设计一个宣传海报，构建一个邮件列表，邮递宣传海报，跟踪市场反应。在制作用户故事地图的最后环节，发现要完成Mimi产品中所有音乐相关的事情是不可能的，然而，制作一个更快更容易地发送宣传海报的软件看起来是个好主意。后来的事实证明这确实是个好主意。
Mimi在Gary的努力下最终发布了，Mimi目前每月发送上百万条信息。卓越的用户体验让Mimi好像是一个艺术品。同时，我们当时构建的用户故事待办列表仍然可以从最高的视角观察整个系统。
扁平的用户故事待办列表是无效的
