您当前的位置: （序言，之一，之二，之三，之四）
介系嘛故戏
用户故事嘛谁还不知道，如果大家仔细看我们第一个月的截图，就能看到所有故事的描述都被预先置为模板“作为……，可以……，以便……”，就等着填入实际内容了，可是没想到，怪物来了。请看介几个都系嘛故戏：
1. 如果把“保存按钮”统一放在页面上端而非下面，有些屏幕上侧控件的修改，就无需滚屏即可保存。
2. 所有XX字段，统一改为4000长度的nvarchar。
……
第一个勉强可以写为：“作为一个用户，可以方便地点击上端的保存按钮，以便在某些控件修改的时候无需滚屏即可保存”，但是这个故事颗粒度显得过小，开发可能只需要1小时，而在客户眼中，也不应该和“作为一个用户，可以对故事进行编辑，以便……”放在一起，太晃眼。
第二个故事，则找不到“用户”的位置，因为它是我们自己要做的改进，用户完全可以不感知，产品经理不知道甚至都没事。
这类故事怎么办呢？
分类目的
国内的若干描述用户故事的图书中，《用户故事与敏捷开发》算是内容最为丰富的，但也没有明确提及用户故事的分类。
怎样分类呢？有些一望而知的词汇似乎可以选择：史诗故事，用户故事，重构，增强，缺陷……但是它们之间到底是什么关系，这样分类的目的何在？如果不能解决这个根本问题，分类方法就是错误的。
逐渐地，我们开始注意到我们有几种不同的场景，希望看到不同的故事。
第一个场景，是产品经理审视第三个月做出来的那个故事树，以决定在哪里增加新的故事。在这个场景中，产品经理希望静态地查看所有已经开发过的“功能”，由于故事数量庞大，只能展示那些用户“粗略”地评价产品的时候，就能感觉到对自己有价值的故事。而增强、重构、缺陷等，都不太需要显示。
第二个场景，是产品经理审视当第二个月做出来的那个“迭代-故事”视图，了解前二、三个迭代所作的功能，以及为未来的二、三个迭代分配故事。这个时候，要了解的信息要详细地多，从客户能感知的功能、对功能的增强、内部的重构乃至缺陷，都要有。
第三个场景，还没有遇到但是却能预见，就是在产品上市后，每个版本的“发版”报告。里边会有新产生的功能，已有功能的增强，由用户报告且已修复的缺陷等；但重构、内部缺陷等就不需要了。
其他场景……
在各种场景的不同需求中，逐渐显露出两个较为清晰的维度：可见度，颗粒度。
前者决定了客户-产品经理-开发团队的可见类型；后者则决定了整体-版本的展示类型。