许多Scrum团队用用户故事来打造产品的待办事项列表。但是，当某个迭代(sprint)承载一个比较大的故事，可能会引发很多问题。通常建议是把用户故事拆小到团队可以在每个迭代完成6-10个。那么问题来了，为什么要这么做呢？
更快的获取反馈
如果是小的用户故事，团队通常可以在1-3天内完成并且很快就可以从产品经理或者其他干系人那里获得反馈意见或建议，而不是等到迭代末再发出。特别是如果DoD (Definition of Done)包含了验收性测试(UAT)，那就更需要更快速的反馈了。
更快的错误修复
偷偷告诉你们，程序猿们一般只能比较清晰的记得24小时内写的代码。如果在此期间收到反馈或发现Bug，他们会非常快就能搞定。当隔了几天，修复时间就像反记忆曲线一样暴增。
价值低的需求排后
当用户故事被拆分成多个小故事后，产品经理会对整个待办列表排个序，这样 原有大需求中的高价值部分可能会被排前面，而低价值部分会排后面。这样团队将会持续在开发“更精确的”高优先级需求。
更好的预测
假设团队每个迭代的速率是17个故事点，并通常是做8~13大小的用户故事。那么很有可能在迭代结束的时候，其中有一两个需求会没完成。这样，团队的速率值就会非常波动，可能8~21，甚至更多。
如果团队持续做的是类似3个故事点这样的需求，那么开发速率就会比较稳定，这样团队就可以更准确可靠的在计划会议上做估算和排期。
更多的信任
如果每个迭代稳定交付一样多的需求，那么开发团队的做估算将会更可靠。这样可以建立开发团与产品团队以及干系人直接的信任桥梁。
加强团队精神
人们喜欢成就感，每个迭代都完成6-8个用户故事会增强大家的团队精神。想想，你是喜欢看0比0的足球赛还是喜欢看3比2的？
节约估算时间
如果开发团队稳定交付6-8个用户故事，很有可能这些用户故事就都是差不多大小。意味着下次，开发团队不需要去估算每个用户故事，只需要计算有几个。
减轻风险
更好的拆分意味着更多的分析。因此开发团队有很大机会可以识别并减轻风险，不然，对下个迭代只是略知轮廓。凡是预则立，情报有如武装。
迭代内更方便分配工作
我经常看见大家经常在迭代末超负荷工作。这个问题本来是很复杂的，但是，可以通过更好的拆分需求，小需求会让大家平行均衡的工作，改善团队的绩效。
结语
- 需求过大会引发很多问题
- 而好的拆分可以让你更快获取反馈，更快修复问题，有效的排后价值低的需求，增加信任和增强团队精神，节约评估时间，减轻风险，并改善团队绩效。
The Principles of Product Development Flow
延伸阅读
User Stories Applied
Agile Estimation and Planning
On WIP limits, Velocity and Variability
RingCentral敏捷教练
不懂技术的产品经理不是好教练！
长按二维码关注