每次到新的客户那里，总会发现在“做Scrum”的团队，它们不能在本Sprint完成所有的用户故事，因此在不少公司的Scrum团队中甚至衍生出了开发Sprint，测试Sprint。甚至在去年有一家自以为Scrum做的不错的公司，做了这方面的分享，自认为这是一个聪明的改进，把它称之为“具有其公司特色的Scrum”。

症状

• 开发Sprint、测试Sprint、T-6、Hardening Sprint、发布Sprint
• Sprint结束的时候，大部分用户故事完不成
• 测试人员要等到Sprint结尾的时候才开始测试Sprint计划会议承诺的故事
• 很难给故事定义明确的验收条件
• Sprint开始几天内，没有用户故事完成

诊断
在Backlog中，高优先级的那部分故事，应该是SMART的（Specific, Measurable, Attainable, Resource, Timely）。这跟设定目标一个道理，远期的目标可以是大的、方向性的；但是近期的目标一定要具体，可完成的。不SMART的高优先级故事，会导致如下问题：

• 很难完成Sprint承诺，测试人员在测试上一个Sprint的故事时，发现的bug会冲击到本Sprint的计划，从而导致本Sprint的故事延期
• 排优先级十分困难，需要pk已“完成”的故事中的bug与当前Sprint中故事的优先级
• 很难获得准确的开发速率(Velocity)，因此很难预测发布计划。由于每个Sprint中“完成”的故事，实际上并没有完成，造成了较高开发速率的假象，但是项目后期，还是需要很大投入去维护
• 缺失团队统一的Sprint目标，开发和测试人员的目标不一致，而这些团队成员的目标又与组织的目标（把功能完成、上线、获得客户）不一致。很难形成团队合力。

症因

• 开发测试人员之间角色过于分明，过于强调工作移交而不是协同
• 开发团队不愿意帮助PO切分用户故事、定义验收条件
• 团队不掌握需求切分的技能
• 测试人员不情愿重复测试同一个功能
• 缺乏自动化测试支持

处方

• 引入周期性的产品待办事项梳理活动
• 团队一起切高优先级的用户故事，确保故事粒度在单个Sprint可以完成4-10个范围内
• 引入实例化需求(Specification By Example)实践、用例子描述验收条件，并将之变成自动化测试
• 对于一个用户故事如果需要过多场景或者测试用例来验证，需要把它从用户角度切分