2.5. 小的

有些故事可能太大，有些可能太小，有些则刚刚好。

故事的大小很关键，故事太大或太小都无助于制定计划。

使用史诗故事来开展工作会很困难，因为它们通常包含多个故事。

举个例子：在一个旅行预订网站，“一个用户可以计划一次度假”是一个史诗故事。对于任何旅行预订系统，计划一次度假都是非常重要的供，包括一系列任务。史诗故事需要分成更小的故事。

合适的故事大小最终取决于团队、它的容量以及所使用的技术。

分割故事

史诗故事通常分为以下两种。

复合故事有多个小故事组成的史诗故事。在做系统初始设计计划是，复合故事可能是比较合适的，但是通常它都能分割成多个更小的故事。

比如，“用户可以发布他的简历”这个故事，可以分割成以下的故事。

一般有很多方法来分解一个复合故事。上面的分解方法，沿用一种常见的分解方式，即按照“创建”、“编辑”和“删除”这些动作来分解故事。

另一个可行的方法是根据数据边界来分解。比如，我们将简历的各种部分当成单独的部分来增加和修改。

不同于复合故事，复杂故事是本身就很大并且不容易分解的故事。如果一个故事因为不确定性而复杂，可以将它分为两个故事：一个调研的故事和一个开放的故事。

例如，假设给开发人员这样一个故事：“公司可以用信用卡支付发布职位的费用”，但没有一个开发人员曾经做过处理信用卡相关的工作。他们可以将故事这样分割：

第一个故事会让一个或多个开发人员实施探针试验。这样分割复杂故事时，我们仍然非常可能定义需要花多少时间来进行调研。

当我们开发新的算法或扩展已知算法时，复杂故事是很普遍的。

如果有可坑，一种较好的做法是把调研的故事放在一轮迭代中，另外的故事放在接下来的一轮或几轮迭代中。

一般我们只能对调研的故事做评估，将另一个无法估计的故事与调研故事放在同一轮迭代中，不确定性会高于平春，因为我们无法知道在哪一轮迭代中能完成多少工作。

对无法估计的故事进行分解，主要的好处是允许把调研工作从新功能中分离出来，以便对调研工作排列出优先级。

有时候，故事太小了。对于太小的故事，开发人员会说，他不想写下这个故事或者对它进行评估，因为那么做可能比实施该故事花的时间更长。

一个比较好的方法通常是将这些太小的故事合并到需要半天活几天完成的故事中。给合并后的故事命名后，就可以同其他故事一样计划实现它。