提示：本文共有 565 个字，阅读大概需要 2 分钟。
一、 团队改进前概况
属于工具类软件产品团队，产品属于公司重要产品。团队成员包括需求2人，开发7人，测试4人。
团队转型前的情况：
项目组开发每三个月后，都需要有3-4周的系统测试；根据项目前期质量需要，迭代开发过程中的质量活动较多，且基本每个环节都需要交付相关文档（需求交底-反交底-详细设计-详细设计评审-编码-自测-代码审查-需求验证-测试-修改Bug）；迭代评价的过程度量指标较多，每个迭代进行度量指标统计及分析至少需要2h。团队转型之前面临的问题：
交付周期很难缩短-阶段性的存在3-4周的系统测试来保证质量；时间“浪费多”-成员被要求写很多过程文档，过程度量指标数据统计非常多，团队成员感觉不到有价值；迭代的交付主要集中在迭代结束前三天，测试的压力较大，经常出现因为开发的延迟交付导致测试无法在迭代内完成，迭代价值交付率低；开发工作不开心（强制的繁冗的流程都要写文档）。二、 团队改进后效果
团队改进历程
敏捷转型历时7个月后，团队打造成需求、开发、测试真正意义上的一个整体团队，完成Scrum、用户故事、发布计划的深度实践，用户故事+Scrum研发规则能够顺畅运转。
团队阶段改进成效
平均迭代计划完成率90%以上，1-2个迭代（迭代周期2周）可稳定交付一个版本；产品发版周期由15天降到13天,“抢”出一个短迭代；迭代千行BUG率<0.9，比改进前提升了25%-30%；需求用户验证方法基于用户故事的场景式验证，提升了用户的参与度和满意度。三、改进启发
本次案例是我2016年教练指导的团队，在我开始指导之前，团队已经能够“独立运转”基本的Scrum框架，但是还是遇到了诸多问题，在需求方面更是存在文前的若干问题场景。
后来了解到，在这之前需求人员一直和团队成员保持着一定的距离。2名需求人员属于产品线内的需求部门，而团队（开发+测试）则是单独的。当有需求需要导入时，需求人员拿着需求规格书对团队进行讲解交底，释疑，当团队认为没有问题了，就进入二周周期的迭代。结果，虽然团队的SCRUM框架貌似已经运转的有模有样，但是还存在着这样那样的问题。
原因是什么？经过分析，我认为主要有两点，第一，团队对Scrum框架的理解和使用还只是很浅的层次，实际并没有真正领悟敏捷的价值观，尤其是“可工作的软件高于面面俱到的文档”这一条。其次，团队在需求方面，没有使用用户故事方法，还是使用传统的需求规格说明书导入团队。形式上的Scrum团队加上分离的PO再加上非敏捷的需求，导致团队问题多多。
为了解决问题，我对2名需求人员（PO）进行了用户故事方法系统化的培训和辅导。
在用户故事编写方面，严格要求PO(2名需求人员)按照用户故事经典三段论的格式进行编写。并有效采用了史诗故事和用户故事两层需求描述的层级。在用户故事验收标准方面，根据产品情况采用了“需求点”的验证方式。
在用户故事估算方面，采用了计划扑克进行估算，开发与测试同时参与估算，通过估算，大家对需求的理解达成了真正的一致。
在发布计划方面，采用了时间驱动的发布计划。
在迭代过程中，当开发认为他已经完成了故事的开发时，会召集PO和测试进行MiniShow,做到了及早用可工作的软件来验证PO开发测试的对需求理解是否真正的一致，如果发现彼此的理解存在偏差，会及时进行修正。
当测试完成后，PO会进行需求的用户验证，因为采用了用户故事方法。用户能够得以场景式的进行功能验证，更容易参与，从而用户的反馈更加保真。
在团队方面，从PO角色职责的角度，对需求人员进行了多次的点对点辅导。使PO主动打破了职能墙，开始积极参与团队的各项活动中，使需求人员真正成为了团队的PO。
经过一段时间的改进，相关Leader终于意识到过多过程文档编写的弊端，减少了过程文档的要求，降低了团队成员不必要的浪费。
当2名需求人员成长为成熟的PO,在分享敏捷改进的经验感悟时，她们总结出用户故事的实践价值如下：
便于团队成员内部快捷地达成真正的一致，节省了沟通成本；便于迭代的精准计划、价值导向的适应性调整，增强了团队成员的目标感；便于快速稳定交付，提升了团队的效率产能；便于用户提供业务场景层级的价值反馈，提升了用户验证的质量；促进团队从关注任务到关注价值的思维转变,增强了团队整体对产品业务的理解，提升了团队的凝聚力。
看到此处说明本文对你还是有帮助的，关于“润物细无声”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
