文长：2770字
时长：8分钟
针对人群：用户体验设计师，业务分析师，产品经理，研发工程师
1 概念
什么是用户故事：
迭代开发的一种工具
代表了可开发的一个工作单元
帮助我们跟踪一个功能的生命周期
什么是用户故事地图：
一个有风向的图表
横轴为时间线，放置延时间线的用户故事
纵轴为优先级，自上而下
覆盖所有用户故事，表达需求全景
为什么使用用户故事?
从设计赋能角度来讲，用户故事地图可以帮助设计师：
从产品计划层面，提升产品用户体验，避免沉入细节之中；
找到一种落地产品思维的方法，即平衡用户价值、产品价值、开发成本三者的关系；
关注项目和产品，设计出落地、有效的产品方案，避免理想化；
从项目管理角度，用户故事地图可以解决以下问题：
从团队协作角度，用户故事可以降低沟通与达成共识的成本，将关注力更多集中在产品上。
只见树木不见森林，重要内容埋没在细节中，难以排列优先级；
无法看到版本贡献功能的完整价值流；
无法方便的使用迭代方法跟踪、优化内容，确定版本计划和目标；
用户故事简述：
作为一个（角色）: 谁要使用这个功能。
为想要（功能）: 需要完成什么样的功能。
以便于（价值）: 为什么需要这个功能，带来什么样的价值(用户价值和组织价值)。
2 准则
用户故事地图要素：
构建用户故事地图需要：时间线，用户活动，用户任务，用户故事，故事地图结构：用于实现目标的用户功能 > 活动 > 任务 > 史诗 > 故事
将用户要素从左向右拖动到地图的顶行。地图顶行中的每个功能都是呼叫用户活动。
创建完成活动所需的许多步骤，称为用户任务。
这些用户任务中的每一个都可以分解为多个史诗。
在史诗下，可以定义用户故事列表，其大小适合放入sprint。
用户故事的3C原则
3C原则是由Ron Jeffries提出的。它包括三个部分：
Card卡片，用来简要描述软件特性或改进点。
描述的内容简洁、词汇含义统一，项目成员不会对同一内容有差异性理解；
这些卡片用于后续的沟通、对需求内容的组织和排列优先级；
Conversation 交谈 ，与Product Owner（或客户）交谈来明确细节。
卡片的内容是由团队在沟通中获得，而非由同一个人输出或更新的，不然它与传统的需求分析方法无异；
项目成员需要一起就卡片内容进行讨论。在复杂逻辑中，梳理出清晰的需求脉络，并在这一过程中，达到共识和理解的统一。
Confirmation 确认，每个故事应具有验收标准（验收条件），能够确认被正确完成。
以始为终，先行确认以怎样的结果，来判断开发任务的完成；
它保证每个故事都是独立的、完整的逻辑，可以单独交付；
它为驱动测试驱动开发、行为驱动开发和持续集成提供可能。
用户故事原则：
I 独立的（Idependent）：独立且完整，不依赖于其他任何用户故事；
N 可谈判的（Negotiable）：引导团队跟干系人之间对话和谈判的介质。在任何时候，用户故事都可以被改写甚至丢弃。一个用户故事不会像石头一样固定不变，直到它将要在接下来的Sprint里被实现；
V 有价值的（Valuable）：需要将价值给干系人，不论是最终用户还是采购者；
E 可估算的（Estimable）：团队需要能够粗略地估算出完成用户故事所需工作量规模；
S 小规模的(Small)：以一个大的“占位符”开始其生命周期。随着时间的推移，当人们对用户故事所表达的愿望的复杂度更加了解时，这个较大的“占位符”就将被拆分成小的用户故事。当最重要的那些用户故事将进入Sprint被实现并交付时，它们需要变得足够小，这样才能在一个Sprint里被完成。
T 可测试的(Testable)：一个用户故事必须提供必要的信息，清楚地界定了故事的验收标准，这样才能在它完成时判断是否验收。
3 创建用户故事地图
用户故事地图是一个用于需求收集的4级层次结构。故事地图从不同来源（即积压）收集的用户特征集合开始，这些用户特征将通过执行某些任务作为活动来实现。这些任务可以转换为史诗后转换为软件开发的用户故事。
产品定义
一般是在故事编写工作坊准备阶段，首先由PD主导产出，主要有几点内容：
产品的目标用户。
解决了哪些问题。
用户目标。
产品目标。
梳理骨干故事
写出不同颗粒度的故事，需要设计师把控故事的大小，这段故事可以再往下梳理一层颗粒度更小一点的故事。这样骨干故事就有两层，一级故事和二级故事，故事的发生从左至右是一个叙事流。
拆分故事
在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。
沟通确认
这里我们的故事已经变得很丰满，甚至变得臃肿，所以沟通确认变得极为重要。我们在这步需要花费相对多的时间，大家对内容进行对标、充足讨论，把公认的留下来，无用的踢出掉。同时可以区分要做的故事细节的优先级。
4 建立用户故事卡
目的：
卡与迭代的关系
卡是迭代开发的一个工具
卡代表了一个可以的工作单位
帮助我们跟踪一个功能的生命周期
管理卡片：
估计工时
分配工作
追踪进度
如何使用？
书写故事卡；
将卡放在墙内（物理墙/数字墙）
领卡需要与QA/BA澄清需求(一人不能有两张正在做的卡)
故事卡完成后需要做Desck Check（block里的卡片要尽快消灭）
5 产品迭代
IPM：Iteration Plan Meeting，迭代计划会议主要是跟客户保持沟通与信息更新的会议。
下一个迭代的Story。
对下一个迭代的期望。
团队的人员可用性。
风险的评估总结。
敏捷宣言里面有一条：客户协作优于合同谈判。在Scrum团队中有一个角色叫做产品负责人，Ta的核心职责是确保业务需求的清晰和透明，保证开发团队对业务有足够的了解，并将这些待完成的业务需求（Story）按照优先级排列出来，按照任务卡的方式来驱动团队的开发。
IPM的主要产出是下一个迭代中完成的Story，这些Story即为下一个Story要完成的目标，通过敏捷看板工具来管理它们
Sprint：列表：业务流，Sprint1，Sprint2，Sprint3-N，已交付的故事。业务流就是史诗故事，每个史诗故事一个泳道。Sprint1，Sprint2，Sprint3-N里面是不同史诗故事拆分出来的用故事，并且根据优先级放到了不同的 Sprint 里面，横向的泳道代表的是史诗故事和史诗故事拆分的子故事的对应关系。
burn down chart：燃尽图，一个sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。
Retro：（回顾）即retrospective的简写，团队针对目前状态总结，目的为保持好的方面及加强，做的欠佳的方面一起讨论改进措施，并尽力落实。在实践中摸索出适合团队的最佳实践，引导团队和个人不断自我完善，追求卓越。
确认构建安全的环境；
建立几项总结指标（well，less well，suggestion，action）前三项列出看法，第四项针对前三总结；
一个点写在一张便利贴，分栏贴上墙；
将同一类的问题归纳起来，总结出相应的解决措施；
Iteration 栏中的sticker指派并落实。
往期精彩回顾
点击【在看】+转发【朋友圈】对我最大的支持