用户故事（User Story）是从用户的角度来描述产品需求，可以是功能性需求，也可以是非功能性需求，如性能需求等。简言之，用户故事就是通过系统或产品完成有市场价值的事情。
假设有个项目团队的客户是VoLTE语音网关的设备制造商，要求项目团队为用户提供一种实现三方通话的语音业务流程的软件。Product Owner在与客户沟通需求的时候，客户明确要求用户A（假设是主席方）摘机，拨打用户B的电话；用户B摘机与用户A通话；用户A拍插簧，拨打用户C的电话；用户C摘机与用户A通话；用户A再次拍插簧，按键3，用户A、B和C三方通话。
上述客户描述的需求是一个流程，即用户通过VoLTE可以完成一个有价值的目标（实现三方语音通话），这样的需求就是一个用户故事。
如果想要记下这个用户故事，我们可能会用这样的格式：
名称：三方语音通话流程
事件：
（1）用户A摘机，拨打用户B的电话，用户B的电话振铃。
（2）用户B摘机与用户A通话。
（3）用户A拍插簧，拨打用户C的电话，用户C的电话振铃。
（4）用户C摘机与用户A通话。
（5）用户A再次拍插簧，按键3。
（6）用户A、B和C三方通话。
应当注意到，一个用户故事里面的事件可以这样描述：用户做了XX操作触发系统产生YY现象，如是循环。
换言之，用户故事是以客户能够明白和容易理解的方式描述某系统或者产品的外在表现行为，而完全忽略系统或者产品的内在实现逻辑。就上述需求而言，以下的内部实现逻辑就不应该出现在用户故事中：
（1）用户A摘机，拨打用户B的电话，用户A侧的VoLTE系统发出INVITE信令，用户B侧的VoLTE系统收到INVITE信令后发送180 Ring信令给用户A，用户B的电话振铃。
（2）用户B摘机，用户B侧的VoLTE系统发送200 OK给用户A。
（3）用户A拍插簧，拨打用户C的电话，用户A侧的VoLTE系统发送re-INVITE信令给用户C，用户C侧的VoLTE系统发送180 Ring给用户A，用户C的电话振铃。
（4）用户C摘机，用户C侧的VoLTE系统发送200 OK给用户A。
（5）用户A再次拍插簧，用户A侧的VoLTE系统发送INVITE／sdp，按键3后，用户A侧的VoLTE系统分别向用户B侧和用户C侧的VoLTE系统发送INVITE／sdp，以恢复与用户B和用户C的通话。
（6）用户A、B和C三方通话。
再比如，某博物馆要求在展览馆内设置一套视频监控系统，以对各个橱窗中的展品进行实时监控，如遇盗窃或者非法入侵，系统会自动报警。
我们可这样描述该用户故事：
（1）在展览馆内设置若干摄像头，获取展品的实时监控图像。
（2）正常情况下，实时监控图像中只有展品。
（3）非正常（如发生盗窃等）情况下，实时监控图像中出现异常，那么视频监控系统发送警报并通知安保人员。
以下的实现逻辑则不应该出现在用户故事中：
（1）正常情况下，视频监控系统根据抓取到的若干图像形成正常图像模板。
（2）设定一个阈值范围，当前监控到的实时图像与正常图像模板的像素差在阈值范围之外，表明有非法入侵，触发报警器进行报警。
（3）视频监控系统通过Notify信令通知中央监控室。
用户故事通常按照如下格式来描述：
英文：As a＜Role＞，I want to＜Activity＞，so that＜Business Value＞．
中文：作为一个＜用户角色＞，我想要＜用户活动＞，以便于＜商业价值＞。
“用户角色”不能写成“用户”，而是要把用户区别对待，这样才能更好地理解他们使用什么功能，如何使用，为何使用。
“用户活动”即用户亲自执行的操作。用户活动不能简单等同于产品功能，虽然产品功能可能也提供了用户所需的价值，但极有可能不便于用户操作。
“商业价值”是完成操作后，客户所得到的益处。商业价值通常包含诸如“高效地”“有效降低成本”“显著增强了系统稳定性能”等褒义表述或吸引人的内容。(www.xing528.com)
面向用户价值编写用户故事举例（A例是推荐写法，B例不是推荐写法）
用户故事Ⅰ：玩家排名
A．作为一个排名靠后的付费玩家，可以通过游戏闯关升级获得积分，以便让自身在玩家列表中的排名上升。
B．作为一个玩家，可以通过闯关，以使排名上升。
用户故事Ⅱ：调动人员权限
A．作为管理员，可以在有人员调动时查询和修改其权限，以保证权限顺利转移。
B．作为管理员，可以查询和调整所有用户的权限，以改变某些所需调整的用户权限。
用户故事Ⅲ：防打扰功能
A．作为一个用户，可以选择“认可所有相似操作”，以便同意或禁止连续地修改硬盘、访问网络的操作。
B．作为一个用户，可以在安装软件时选择“认可本次安装操作”，以便一键完成正常的安装操作。
用户故事的核心是“用户”，因此对用户进行建模有着非常重要的现实意义。对用户建模的目的是理解哪些用户可能使用该产品或访问该网站，他们为解决哪些问题、为达到哪些目的而来。有效的用户建模，可以保证不同用户都能方便地访问其功能，使用产品后也更容易获得特定的价值。反之，将大量功能无序地摆放在用户面前，不但不会增加价值，反而会令用户无所适从。
用户建模“四部曲”
（1）列出尽可能多的用户，这些用户与故事之间存在不同程度的需求关系。
（2）识别关键用户，包括主要的购买决策者和使用者。
（3）面向关键用户编写故事，并设置用户故事为高优先级。
（4）合并次要用户，选择性地为次要用户编写用户故事并设置为低优先级。
Scrum经典管理工具——看板和便利贴
用户故事的载体是看板，或者叫敏捷看板、故事墙、故事板，是一块物理看板，看板上至少绘有三块区域，分别为Scrum团队待做事项列表区域、正在实施事项列表区域和已完成事项列表区域。如图3-7所示，每块区域都贴有若干便利贴，便利贴上写有用户故事，Scrum团队成员每天的任务进展就可以通过不同的便利贴在不同区域之间流动，进行可视化展现。换言之，Scrum看板就是团队成员实施用户故事的进度的可视化体现，通过观察看板不同区域的便利贴，便可以清楚地掌握Scrum团队当前完成了哪些用户故事，哪些是正在实施中的，还有哪些是还未实施的。
当然，Scrum团队也可以定制看板展示的内容，很多团队把燃尽图和障碍项添加到看板上。Scrum团队成员每天负责将所有任务剩余时间累加，然后以图表形式绘制在看板上，形成燃尽图，如图3-8所示。
图3-7 Scrum经典管理工具——看板和便利贴
图3-8 Scrum燃尽图
燃尽图上有两条线，下侧的线表示计划中的燃尽图走向，上侧的线表示实际绘制出来的走向。从图3-8可以明显看出，最开始任务消耗比较慢，说明任务可能遇到了问题，暂时没有解决方案。到了第四天，燃尽图有一个明显的下行，可能是任务得到了解决，也可能是任务被取消。
看板和便利贴有哪些优点？
●直观。通过看板，团队成员可以非常直观地了解项目的进展。
●方便。只需要一块看板、几张便利贴、一支水笔即可。
●趣味。与代码和图纸相比，“看板＋便利贴”的趣味性较强，更易于被大多数人看懂并接受。
但不可否认的是，“看板＋便利贴”也存在一些缺陷，主要体现在团队的历史进度数据无法保存；看板尺寸限制导致其可承载的信息相对有限；便利贴受物理、环境因素影响较大，比如风的影响，或者便利贴不干胶黏性较差等；受地理空间限制，跨地域、跨部门的Scrum团队无法共享看板信息。
针对“看板＋便利贴”实际存在的缺陷，Scrum团队可以借助敏捷工具来很好地克服和解决，比如采用本书附录二所述的Leangoo开源工具以实现Scrum过程的电子化管理。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
