小故事开头
有一句话说得好，用户故事是讲出来的不是写出来的，讲人话，达成统一理解。参加用户故事分析讨论应该是整个开发团队的事情，切莫让BA或者PO独自完成。
用户故事背景
既然是实战，那么从用户故事开始是一个最好的起点。这次的客户连锁咖啡店，由于位置优越，整个写字楼的顾客在早上和中午都会来排队买咖啡，用户体验很差，部分客户由于无法等待选择了外卖和别的竞争对手。为了解决这个问题，咖啡店希望通过一个在线平台来完成客户的在线下单，完成通知的效果，让顾客不必排队等待，也方便外卖人员可以对较远的客户进行送单。
对于这样的需求怎么构建用户故事、用户故事地图和用户故事迭代计划呢？
用户故事
构建用户故事首先从构建角色开始，不同的角色所期望的价值不同，例如有人需要外卖可以送、有人需要除了咖啡以外的小点心、有人需要现场有可以讨论的座椅等。
规划角色
这里根据用户调查分布做统计分类假设了四个角色并且罗列他们对平台的期望值，覆盖了各个年龄层的主要消费意图，这里并没有做一个虚拟的反向用户。
王某：68岁（长期加班所以都是白胡子老爷爷了），对咖啡有非常高的要求陈某:35，希望能够找到适合自己的咖啡
能够专业的介绍咖啡的产地信息、加工工艺等能够专业的给出多种口味选择及背后的区别
王某：22岁，在校女学生，追求性价比高天某：28岁，办公室女性，要有腔调
方便快捷，可以选多杯给出详细的卡路里
罗列用户故事
Teams根据针对上面的每一个用户角色做用户故事及价值拆分，提取功能点。
1.作为一个对咖啡非常有追求的客户，他希望能够分享自己对咖啡的理解，从而和更多志同道合的朋友认识。
1.1用户可以评价自己品尝的咖啡
1.2用户可以查看每款咖啡的评价
1.3用户可以具备自己的主页罗列咖啡的相关评价
1.4用户可以添加别的用户成为好友
1.5用户可以在每个咖啡厅找到小组，组沟通
1.6用户可以自己设定咖啡豆种类、加工工艺和材料配比，定制自己的咖啡。
2.作为一个经常喝咖啡的客户，他希望能够品尝更多种类的咖啡，从而找到适合自己的咖啡。
2.1用户可以方便根据分类来查找咖啡
2.2用户可以根据评价来查找咖啡
2.3用户可以根据每个咖啡厅的推荐列表来获取推荐咖啡
2.4用户会被推送根据其点单习惯和同类大数据比较后的推荐咖啡种类
3.作为一个在校的学生，她讨厌速溶咖啡希望能够喝到高性价比的咖啡，从而可以逐步培养对咖啡的品味。
3.1用户可以方便的查询某个地区附近的咖啡店在哪里
3.2用户可以方便的预定多种口味的多杯
3.3用户需要积分功能，并且可以领取折扣券
3.4用户可以设定提前预定的提货时间
3.5用户可以看到别的用户编写的心得体会，了解喝咖啡的一些顺序和特点
4.作为一个职场Lady，她希望能够和别人喝不太一样的种类，从而培养自己的强调。
4.1用户可以定制每次取货的别名
4.2特殊用户等级可以具有专属包装袋
4.3定时提供限量版的口味、杯子
4.4支持自带咖啡杯
评估用户故事优先级
现在我们看到很多用户故事点出来，这些用户故事点需要排列优先级这样才能为后面的MVP最小价值交付提供判断依据。用户故事的优先级有很多种评判方法，这里涉及到成本、主要针对用户及活动推广策略等。作为一家新兴连锁咖啡店，主要用户群还是在办公室蓝领，推销活动主要是转发、拉新抵扣，走实实在在的价格补贴策略。
这里将用户故事优先级分为（MoSCoW法则）：
Must：这个迭代一定要做的。比如前面提到的“必需”的功能。
Should：应该做，但若没时间就算了。比如前面提到的“不太需要的”功能。
Could：不太需要的，但有了更好。比如前面提到的“几乎早期版本中不要”的功能。
Would Not：明确说明这个功能不需要做，切勿把功能放到Must，Should or Could里。
1.作为一个对咖啡非常有追求的客户，他希望能够分享自己对咖啡的理解，从而和更多志同道合的朋友认识。
1.1用户可以评价自己品尝的咖啡（Could）
1.2用户可以查看每款咖啡的评价（Could）
1.3用户可以具备自己的主页罗列咖啡的相关评价（Could）
1.4用户可以添加别的用户成为好友（Could）
1.5用户可以在每个咖啡厅找到小组，组沟通（Could）
1.6用户可以自己设定咖啡豆种类、加工工艺和材料配比，定制自己的咖啡。（Should）
2.作为一个经常喝咖啡的客户，他希望能够品尝更多种类的咖啡，从而找到适合自己的咖啡。
2.1用户可以方便根据分类来查找咖啡（Must）
2.2用户可以根据评价来查找咖啡（Could）
2.3用户可以根据每个咖啡厅的推荐列表来获取推荐咖啡（Must）
2.4用户会被推送根据其点单习惯和同类大数据比较后的推荐咖啡种类（Should）
3.作为一个在校的学生，她讨厌速溶咖啡希望能够喝到高性价比的咖啡，从而可以逐步培养对咖啡的品味。
3.1用户可以方便的查询某个地区附近的咖啡店在哪里（Must）
3.2用户可以方便的预定多种口味的多杯（Must）
3.3用户需要积分功能，并且可以领取折扣券（Must）
3.4用户可以设定提前预定的提货时间（Must）
3.5用户可以看到别的用户编写的心得体会，了解喝咖啡的一些顺序和特点（Could）
4.作为一个职场Lady，她希望能够和别人喝不太一样的种类，从而培养自己的强调。
4.1用户可以定制每次取货的别名（Would Not）
4.2特殊用户等级可以具有专属包装袋（Could）
4.3定时提供限量版的口味、杯子（Should）
4.4支持自带咖啡杯（Must）
注意：这里涉及到的后台的基本账户管理，联系地址等功能都没有罗列，而这些功能都是Must的。
评估用户故事大小
在知道优先级之后还需要做一件事情就是评估用户故事的大小，一般来说我们的用户故事分为Epic、Theme、Story三个大小级别。用户故事的大小取决于该用户故事实现的预计工时，根据迭代长度可以确定每次Sprint冲刺所可以完成的用户故事上限，并且在上限中找到合适的MVP。
一般评估用户故事的方法是根据历史经验的，在讨论中如果出现较大误差可以通过T恤分类或者估算扑克来进行讨论。
估算扑克适合少量用户故事的大小讨论，参与讨论的各自提交自己的估算值，如果误差较大则互相阐明理由，再次估算，直道统一。
1.作为一个对咖啡非常有追求的客户，他希望能够分享自己对咖啡的理解，从而和更多志同道合的朋友认识。
1.1用户可以评价自己品尝的咖啡（Could/4）
1.2用户可以查看每款咖啡的评价（Could/4）
1.3用户可以具备自己的主页罗列咖啡的相关评价（Could/24）
1.4用户可以添加别的用户成为好友（Could/4）
1.5用户可以在每个咖啡厅找到小组，组沟通（Could/16）
1.6用户可以自己设定咖啡豆种类、加工工艺和材料配比，定制自己的咖啡。（Should/100）
2.作为一个经常喝咖啡的客户，他希望能够品尝更多种类的咖啡，从而找到适合自己的咖啡。
2.1用户可以方便根据分类来查找咖啡（Must/4）
2.2用户可以根据评价来查找咖啡（Could/4）
2.3用户可以根据每个咖啡厅的推荐列表来获取推荐咖啡（Must/4）
2.4用户会被推送根据其点单习惯和同类大数据比较后的推荐咖啡种类（Should/64）
3.作为一个在校的学生，她讨厌速溶咖啡希望能够喝到高性价比的咖啡，从而可以逐步培养对咖啡的品味。
3.1用户可以方便的查询某个地区附近的咖啡店在哪里（Must/8）
3.2用户可以方便的预定多种口味的多杯（Must/8）
3.3用户需要积分功能，并且可以领取折扣券（Must/16）
3.4用户可以设定提前预定的提货时间（Must/4）
3.5用户可以看到别的用户编写的心得体会，了解喝咖啡的一些顺序和特点（Could/4）
4.作为一个职场Lady，她希望能够和别人喝不太一样的种类，从而培养自己的强调。
4.1用户可以定制每次取货的别名（Would Not/4）
4.2特殊用户等级可以具有专属包装袋（Could/8）
4.3定时提供限量版的口味、杯子（Should/8）
4.4支持自带咖啡杯（Must/4）
5.用户账户管理（Must/16）
6.咖啡列表查询（Must/16）
7.购物车、下单（Must/16）
8.后台店家信息维护（Must/32）
用户故事地图
在罗列了所有的用户故事后，接着就需要构建用户故事地图了，首先应该构造一个用户使用的骨干。
作为一个用户的使用过程应该是：
定位到门店->查询咖啡->选择下单信息->等待提醒取单->取单完成交易->评价获取奖励
基于这个骨干将用户故事根据优先级分类放在对应的节点下，形成基本用户故事地图（这里还对用户当时的心态做了说明）。
定位到门店查询咖啡选择下单信息等待提醒取单取单完成交易评价获取奖励
门店信息管理咖啡列表账户信息店方信息管理客户订单确认客户评价
搜索门店查询取货方式客户信息提示后台订单确认客户活动奖励获取
当前账户咖啡推荐支付方式外送对接订单备注信息
活动推荐活动
探索
need-to-insert-img
need-to-insert-img
need-to-insert-img
need-to-insert-img
need-to-insert-img
need-to-insert-img
need-to-insert-img
惊奇犹豫期待开心炫耀
用户故事迭代计划
为了更快的试错，迭代计划需要遵从最小价值交付（试错）的原则，选择构建成可以交付的最小单元。
定位到门店查询咖啡选择下单信息等待提醒取单取单完成交易评价获取奖励迭代
门店信息管理（门店位置）咖啡列表（不超过一页种类）账户信息店方信息管理（订单信息列表）客户订单确认Sprint1
搜索门店查询支付方式（支付宝）客户信息提示后台订单确认客户评价Sprint2
当前账户咖啡推荐取货方式订单备注信息客户活动奖励获取
门店信息管理活动推荐支付方式（其它）外送对接不规划
活动不规划
用户故事范例
为了帮助大家对具体某一个用户故事有概念，这里单独写一个用户故事，来作为参考。
标题账户信息
描述作为一个用户，需要账户信息记录，来维护其相关信息，从而实现积分，推荐功能。
AC：
用户需要通过短信验证确保手机号码为核心信息；
用户可以上传头像但是大小不能超过5MB；
用户最终可以通过手机短信重置密码；
用户信息包含积分、优惠券；
DOD：
通过代码审核和自动化测试；
接口性能大于100TPS，响应时间1秒内；
可灰度发布生产，并且通过UAT测试；
优先级Must
预估工时16
内容就文章到这里了~喜欢的关注小编点赞哟。该文章转发请附带链接。对敏捷，DevOps感兴趣的同学可以加入咱们的社群，里面有大佬分享相关技术，不怕你学不会，就怕你不来，QQ交流群：243771258交流微信：xiang520and。希望本文对你有所帮助喜欢的可以给小编点赞关注哟~如果喜欢本文，转载须附带本文链接谢谢合作