在发布会议和迭代计划会议中，划分用户故事是一个很重要的活动。但是很多时候，团队成员并不清楚为什么需要小的用户故事，应该怎样划分。常常为这些问题争论不休，因此我在这里做一个回答。

为什么用户故事越小越好
缩短完成用户故事的时间
很多人想当然的认为用户故事大小跟完成的时间是成正比（线性的）。但是事实并不是这样。有研究表明随着用户故事规模的增长，完成它需要的时间会呈非线性的增长。参见“Scale Lean & Agile Development”里面的截图。两倍大小的用户故事需要花五倍的时间来完成。为什么？因为随着其粒度的增大，不确定性(由于缺陷、人的因素，外部依赖等因素)会急剧提高。

减小用户故事大小的差异性
在软件开发中很多时候团队成员都在等待。等待有很多原因，开发人员在等待BA回答需求问题，开发人员在等待架构和代码审查，测试人员在等待开发人员完成开发工作等等。在稀缺资源面前会有一个长长的任务队列。如果能够消除由于资源竞争产生的队列，团队开发的效率就会大大的提高。如何解决，排队理论(Queuing Theory)给了比较好的答案。
根据排队理论，用户故事的不确定性是导致系统开发周期非线性膨胀的主要因素。不确定性的表象有几种：

• 不确定的迭代长度
• 不确定的用户故事集合
• 用户故事大小差距很大
• 团队成员不固定
• 发布时间不固定
• 新的需求到达时间(irregular arrival)不确定。
• 解决方案就是”Leveling the work”，尽量使一切变得确定，稳定。所以需要有Time-box，所以需要把大的任务切成类似大小的小用户故事。

其实在实际生活中排队理论使用最广泛的是电信行业。传输中就是把大的数据分割成很多小的包，从而大大减小了不确定性，提高了系统的效率。只不过可惜的是，大家在开发电信系统的时候没有想到应用排队理论。

将大的用户故事分割成小块有很多好处：

• 减少等待 – 下游的成员不必要等待过长的时间，小用户故事在系统内的流转会更快，从宏观来说变成了一个并行模式而不是串行模式。
• 加快反馈 – 每一个小功能的完成都是一个反馈点，可以及时沟通信息。大块需求导致很多需求的缺陷往往到最终测试的时候才能发现，如果不能及早完成，尽快测试，缺陷会越来越难以解决。软件很少一次就做好。多次反馈（至少三次）及不断演进才是一个真正把功能做好的策略。
• 减少缺陷 – 沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。
• 更好的衡量进度 – 可以工作的软件能够更好、更真实地反映项目进度状况。
• 人天生只能关注很小部分 – 精力和智力所限。
• 较少的投入获得较早的回报 – 这样可以尽早的达到成本与收入的平衡点。
• 风险小 – 小的功能投入的资源较少。
• 更容易分优先级 – 大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。
• 更容易让每个人接触不同的用户故事 – 用户故事变小，也会更简单，因此很容易让不同人同时去完成。

怎样划分用户故事？

• 主要是要从客户角度对用户故事进行划分，具体可以：
• 按照不同操作 – 添加、删除、修改、浏览等
• 按照数据 – 可以浏览产品名和介绍、可以浏览产品价格
• 按照特性 – 易用性、性能、兼容性、并发性等等
• 按照角色 – 从不同用户角度
• 按照投入的人力 – 比如要完成信用卡支付(Visa, Master, AmericanExperess)，可以分成三个故事来实现。
• 。。。