用户故事拆分的好坏经常是Team能否很好达成迭代目标的一个重要因素。将Sprint Backlog合理的拆分，可以让迭代内任务估算更容易，同时降低了任务间的依赖，让Team的效率也会更高，本周和Team进行了一次用户故事拆分，今天就分享一下这期间的一个有意思的感受。
团队正在讨论拆分的是一个预计3天能完成的中型用户故事。初始拆分是3个子任务，每个任务之间会有先后顺序依赖，也就是必须按顺序完成。大致任务内容如下：
- 后台数据库的处理逻辑。
- 对应数据库上层的应用层逻辑修改。
- 前台交互的对应变化。
这样拆分的每一个任务需要一天的工作量。最后QA需要在3天后开始测试。 于是我提了一个问题“如果只有1天而不是3天交付这个功能，并需要保证该用户故事最小MVP，你们如何实现这个功能？” 参与任务的几个小伙伴经过简单的思考，马上给出了另一种拆分方案，这次去掉了之前方案里面多余的假设和一些非必要的装饰功能，最后居然真的评估可以在1天内完成这个用户故事。
Bruce有话说
当团队拆分用户故事的时候，往往因为希望完美而增加一些假设和非必要的装饰功能。这时候可以通过今天分享的方式来引导团队转变思考方式，重新审视一下拆分方案的必要性。另外，强力问题是一个有用的手段，通过问题引发团队的思考，跳出当前的思维惯性。
对于用户故事拆分的方法，之前翻译过敏捷大师Mike Cohn的一篇用户故事简单拆分法——5种用户故事拆分法，感兴趣的小伙伴可以看一下。另外还有一个比较全的用户故事拆分图谱，有兴趣的小伙伴可以了解一下。
