轻松搞定用户故事地图

需求金字塔
需求金字塔
需求金字塔
• 金字塔的顶端是需求的目标，也就是解决什么用户或 业务问题？
• 金字塔的中间层次是操作和操作流程，为了实现上面 目标，系统需要支持哪些用户操作？这些操作的流程 是什么样的？
• 金字塔的底层是业务规则，各个操作步骤对应的业务 规则是什么样的？
需求金字塔
• MECE原则是麦肯锡方法的核 心，在各个层次上都要做到：
• 最终，根据排列好的故事优先级，排出迭代计划，并确保 我们的第一个发布越小越好，大约在1-2个迭代后可以发 布第一个MVP版本。
案例讨论
• 某服装公司需要快速开发一套在线服装销售网站，请 讨论完成以下工作：
– 10min：请帮忙输出开发该网站的用户故事地图！ – 5min：请挑出你认为无效的故事，同时补充你认为缺
Userstory212
Userstory232
Userstory21 …
Epic3 Theme31
Epic…
用户故事地图结构
很大的故 事
Epic1
Epic2
Epic3
Epic…
存放类 似故事 的篮子
Theme11
Theme12
Theme21
Theme22
Theme23
Userstory111
Userstory121
Userstory211
Userstory221
Userstory231
Theme31
Time Release1
业务角 度拆分
Userstory122
Userstory212
Userstory232
Userstory21…
Release2
Release和时间线平行，确保在放入Release的过程中考虑故事的完整性。
• 1）条目之间相互独立（ Mutually Exclusive），通俗 的讲就是要“分清”各个条目 ，做到无重叠；
• 2）这些条目作为一个整体要 完全穷举（ Collectively Exhaustive），也就是要“分 净”，做到无遗漏。
• 这两点合起来就是ME-CE。
02
故事地图步骤
用户故事地图步骤
用户故事地图结构
User Activities （主干）
Epic1
Epic2
Theme11
Theme12
Theme21
Theme22
Theme23
User Tasks （梗概）
Userstory111
Userstory121
Userstory211
Userstory221
Userstory231
Userstory122
步骤三：拆分故事
一级需求 二级需求 三级需求
步骤三：拆分故事
• 从业务角度，拆分故事，建议分析维度：故事细节、 想法、痛点、机会……
• 使用静默头脑风暴方式，把自己的想法写在一张卡片 上，相互不干扰，然后每个人大声说出自己的卡片内 容，让所有人了解并贴在墙上。
• 这时不必使用用户故事的标准句法（As a …），因为 每张便签都处于地图的特定位置，大家很容易识别其 所处的场景和角色。
故事地图作用
• 了解整个产品的全貌。 • 找到整个产品的主干，也就是路径。 • 促使产生更多用户故事。
可解决的问题
• 防止只见树木不见林，更容易看清backlog全貌
• 确保backlog覆盖了最重要的用户体验路径，及当前 所规划的场景是否可以为用户提供价值
• 确定发布计划以及发布目标，同时确保早期的发布可 以验证整体架构和解决方案
案 例
用户故事地图
黄河敏捷
01
结构与作用
故事地图产生背景
Backlog中的 需求该如何
产生？
故事地图产生背景
• 用户故事地图就是将story用可视化的方式展现在团 队面前，让团队可以仔细梳理、讨论，确认这个 story包含的内容，最终产出需求进行开发。
• 用户故事地图是Userstory的前传！
步骤三：拆分故事
一级 需求
会控入口
会控界面
二级 需求
会议控制 权限
控制按钮
顶部
中部
底部
个性定制 Time
高
故事 细节
权限管理 控制鉴权 产品Logo 导航栏 版权信息
想法
会控人昵 称
操控区域
痛点
机会
多语言
参会人管 理
优先级
退出会控
关闭会议 室
低
步骤三：拆分故事
• 大家在写想法的时候，可以通过一些问题来刺激大家 脑暴出更多的内容，比如：
步骤一
明确方向
步骤二
骨干故事
步骤三
拆分故事
步骤四
精简故事
步骤一：产品定义
• PO召集3-5人参与故事地图讨论会，讨论以下议题：
– 目标用户，用户目标----用户诉求
用户为什么要用这个?能为用户带来什么价值？
– 产品目பைடு நூலகம்，解决什么问题----业务诉求
我们为什么要做这个?能为我们带来什么价值？
故事地图特点
• 不是另外一种写需求的方式 • 故事是用来讲的，不是用来写的 • 侧重事件发展过程的描述 • 故事不是忽悠，不是夸大
故事的听众
老板
听众
团队
用户
用户故事地图结构
• 地图的核心是一条从左到右的时间线 • 通过时间线和卡片进行约束
– 时间线上第一行放置最大粒度的需求，即Epic – 时间线上第二行放置二级粒度需求，即Theme – 时间线下自上而下放置三级粒度需求，即Userstory
度优先，而非深度，不要过早沉浸到细节中。
步骤二：骨干故事
• 然后，将桌面上所有的便签按类似的任务分为一组。 • 选择另外一个颜色的便签，对每个组命名，作为User
Activities（一级需求） • 最后，对这些摆放好组的便签进行排序，一般按照用
户完成操作的顺序，从左到右摆放
– 如果大家无法决定顺序，那么顺序可能没有那么重要。
• 明确方向，防止迷失方向，陷入设计细节的纠结。
步骤二：骨干故事
• 每个人写下自己认为重要的“所要做的事情”User tasks （二级需求）。
• 完成后，每个人轮流读出自己的内容，并把便签纸放在桌 面上。
– 尽量把故事讲完整，便于对整个产品有全局的印象。 – 做到对产品只见森林不见树木的状态。讲完整的故事，一定要广
– 用户在这步具体做什么? – 用户还有其他选择么? – 出现问题如何处理? – 其他用户来到这里该如何处理? – 使用之后有什么变化？ – 别的产品怎么做？
步骤四：精简故事
• 这时我们的故事已经变得很臃肿。接下来要对卡片内容讨 论，把公认的留下，无用的剔除，同时区分优先级。
– 首先，要对大家写的所有卡片进行对标，排除无效故事。 – 其次，不可能一口吃成胖子，对选定的故事排出优先级。 – 最后，无法梳理清楚的故事卡片，可以先写个占位符。