User Story的常见困难

User Story已经在业内使用了多年，到目前为止，在与业界交流时，仍然存在着不少困难，试图列举下，再来看看解决方法。
常见的困难1：如何分拆故事？ 往往故事来自于史诗，刚开始比较模糊，到后面发现有许多细节要处理，而一个迭代内来不及处理了，如果坚持一个故事在一个迭代内能够处理完，那么这个故事就要分拆。 分拆之后，2个故事是存在上下文关联的，如何保持关联追溯？

常见的困难2：如何处理关联到以前故事的修改升级？ 物理故事卡片难以长期保存，而故事完成后不定何时需要修改，有些故事上线后马上收到反馈，需要在下个迭代修改；有些故事上线2个月后，碰到新的要求需要修改。如何查找以前的故事？如何了解本次修改相关的故事？

常见的困难3：如何估算故事的大小？ 全新的故事与修改的故事分别如何估算？ 故事的大小与 故事所要花费的工作量是什么关系？ 完成故事的任务是否仍然需要估算？

常见的困难4：燃尽图如何绘制？ 如果按故事点作为单位，完成后才算燃尽故事点，那么往往前期的燃尽图比较平坦；如果按剩余工作量工时作为单位，每天每任务的跟踪显得比较繁琐，而且在开始时识别所有的剩余任务工时是很困难的。

<未完待续>