一篇带你读懂用户故事地图

之前在敏捷产品管理系列中，我讲了产品 Backlog 作为敏捷团队管理开发过程的核心，所有的活动和交付物是如何围绕它展开的。我也给你讲了组成产品 Backlog 之一的用户故事又是如何经过 建模、搜集、编写、估算这些过程之后，发挥出它的洪荒之力，让全员快速挖掘需求，理解需求的。

很多看完我文章的小伙伴告诉我已经在敏捷开发这些事件中体会到了可视化和全员深入加入这些好处，但是随之而来的问题也出现了，有小伙伴问我当需求拆分出来的用户故事越全面详细，不可避免的容易丢失产品全景图，有时候大家过度陷入到细节而丢失了用户诉求的本质，严重甚至生产出用户不需要的产品。
所以今天我就来带你通过了解故事地图，来解决你在需求拆分过程中如何保持全景图的问题。

故事地图的目的

首先，我想请大家记住，使用用户故事的目的并不是为了写出更好的用户故事，就像产品开发的目的也并不是开发出产品。停止你对故事模版的追求，就像停止你对完美文档的追求一样。
用户故事地图是一种建立共识的机制，之所以叫“用户故事”，因为故事是要讲的，就像文档只是为了备忘一样。
好的用户故事地图讨论的永远是为谁做和为什么做，而不仅仅是做什么。

谁来描绘故事地图

很多敏捷团队要求 PO 来写所有的故事和开展所有故事对话，不管是