在Release计划会议和Sprint计划会议中，划分用户故事是一个很重要的活动。但是很多时候，团队成员并不清楚为什么需要小的用户故事，应该怎样划分。常常为这些问题争论不休，因此我在这里做一个回答。
为什么用户故事越小越好
缩短完成用户故事的时间
很多人想当然的认为用户故事大小跟完成的时间是成正比（线性的）。但是事实并不是这样。有研究表明随着用户故事规模的增长，完成它需要的时间会呈非线性的增长。参见“Scale
Lean & Agile Development”里面的截图。两倍大小的用户故事需要花五倍的时间来完成。为什么？因为随着其粒度的增大，不确定性(由于缺陷、人的因素，外部依赖等因素)会急剧提高。
减小用户故事大小的差异性
在软件开发中很多时候团队成员都在等待。等待有很多原因，开发人员在等待BA回答需求问题，开发人员在等待架构和代码审查，测试人员在等待开发人员完成开发工作等等。在稀缺资源面前会有一个长长的任务队列。如果能够消除由于资源竞争产生的队列，团队开发的效率就会大大的提高。如何解决，排队理论(Queuing
Theory)给了比较好的答案。根据排队理论，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定性的表象有几种：
不确定的迭代长度
不确定的用户故事集合
用户故事大小差距很大
团队成员不固定发布时间
不固定新的需求到达时间(irregular arrival)不确定。
解决方案就是"Leveling the work"，尽量使一切变得确定，稳定。所以需要有Time-box，所以需要把大的任务切成类似大小的小用户故事。
其实在实际生活中排队理论使用最广泛的是电信行业。传输中就是把大的数据分割成很多小的包，从而大大减小了不确定性，提高了系统的效率。只不过可惜的是，大家在开发电信系统的时候没有想到应用排队理论。
将大的用户故事分割成小块有很多好处：
减少等待 - 下游的成员不必要等待过长的时间，小用户故事在系统内的流转会更快，从宏观来说变成了一个并行模式而不是串行模式。
加快反馈 - 每一个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往到最终测试的时候才能发现，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好。多次反馈（至少三次）及不断演进才是一个真正把功能做好的策略。
减少缺陷 - 沟通更加及时，有题可以及时发现，立刻解决，而不需要过长时间的等待。 更好的衡量进度 - 可以工作的软件能够更好、更真实地反映项目进度状况。
人天生只能关注很小部分 - 精力和智力所限。 较少的投入获得较早的回报 - 这样可以尽早的达到成本与收入的平衡点。
风险小 - 小的功能投入的资源较少。 更容易分优先级 - 大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。
更容易让每个人接触不同的用户故事 - 用户故事变小，也会更简单，因此很容易让不同人同时去完成。
怎样划分用户故事？
主要是要从客户角度对用户故事进行划分，具体可以：
按照不同操作 - 添加、删除、修改、浏览等
按照数据 - 可以浏览产品名和介绍、可以浏览产品价格
按照特性 - 易用性、性能、兼容性、并发性等等按照角色 - 从不同用户角度
按照投入的人力 - 比如要完成信用卡支付(Visa, Master, AmericanExperess)，可以分成三个故事来实现
等等。
关于作者：
滕振宇(Daniel Teng)，爱迪德高级软件经理，InfoQ中文站特约编辑。他是亚洲第一位也是目前唯一一位认证Scrum教练(Certified
Scrum Coach)，Daniel具有多年的敏捷项目（Scrum & XP）实践经验以及丰富的带队经验。
Daniel于2006年1月创建了Irdeto上海研发团队，并将Scrum和XP成功引入了团队。目前该团队主要负责数百万美金级别的大型付费媒体计费及客户关系管理系统的开发及维护，四年中成功发布产品的两个新版本。系统现在在美洲、欧洲以及亚洲的许多国家运行。
Daniel一直致力于将海外的敏捷思想、理论及方法以及实践介绍到国内，帮助国内的软件团队高效并有趣地工作，真正为客户创造价值。作为敏捷社区的活跃分子，Daniel通过博客、InfoQ以及讨论组等宣传敏捷。Daniel经常受邀到各个会议中针对敏捷话题进行演讲，他是敏捷中国2009的讲师，并受邀QCon北京2010以及在CSDN举办的软件开发2.0大会2009等中作关于敏捷的演讲。
| 
