用户故事地图详解

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