用户故事自最早1998年诞生以来，由于其突出的优点，到现在得到了广泛的应用。从最开始的克莱斯勒C3项目，用户故事当中的用户一般是指软件系统的人类用户，这类用户故事一般涉及人机交互界面。
而随着用户故事在多种场合扩展使用，慢慢衍生出另外两类故事。本文试图来整理下新的故事。

新的故事

1，系统故事 System Story
2，赋能故事 Enabler Story，也称推动者故事，或者使能故事

为什么不用技术故事

技术故事，技术一词，含义广泛，因此技术故事有不同的理解。
常见的例子有：

1. 重构某个故事；
2. 非人类的系统担当交互对象；
3. 建设技术债务观测工具；
4. 对某关键模块进行架构设计。
   几乎除了用户故事之外的故事，都曾经被人称为技术故事，所以技术故事成为了一个含义广泛的词语。

系统故事

系统故事是指系统或者组件之间发生的交互。另外一个角度可以理解为非人类用户故事，与用例分析当中的非人类角 {MOD}是相当的情况。
对于复杂组合大应用，中间系统往往并不与人类用户直接交互，往往是与其它系统进行交互。而当前不少组织的分工是安装系统或者模块来划分的，不少组织当中的团队所处理的系统或者模块无论位于何处，都有与其它系统或者模块的交互。这时如果不能快速的重组团队，也就是团队所负责的范围没有变化的话，那么系统故事就是无奈的、必需的选择。
一般的，系统故事所描述的仍然是系统的功能，当然有些情况下深入到系统内部的组件级别，这时描述的是系统内部的功能。

赋能故事

赋能故事，不是用来描述系统功能的，而是用来建设更好的开发测试方法、环境、架构、基础设施等等。
其小类有：

• 改进故事
• 环境建设故事
• 测试准备故事
• 设计架构故事
• 其它

识别多种类型故事的原因

有不少人认为没有必要识别其它类型故事，因为其它事务可以以任务的形态进入到迭代计划。
那么原因就是在迭代计划当中，主要有如下2点：

1. 从思考的角度讲，用户故事和任务是两个层次的事物，对于不同层次的事物对于工作量和优先级的思考是颇有麻烦的；
2. 在电子工具使用的情况下，对于不同类型的条目难以混排在一起。当前流行的Rally和Jira缺省都是按故事来进入到迭代的backlog。

而识别了多种类型故事后，有如下好处：

1. 开发测试系统本身的事物，以及辅助开发测试的事物，所有团队需要处理的事物放在相同层面，同场竞技，能够更好的全面考虑各类事物的优先级和安排；
2. 故事点估算可以跨越不同类型事物，通过故事点可能更好的计划迭代，故事点超越了传统的用例点、功能点等等的范围；
3. 绝大多数支持敏捷的电子工具都能管理单一层面的故事优先级排定。

参考

http://www.stephen-smith.co.uk/treat-technical-stories-as-user-stories/
http://ronjeffries.com/xprog/articles/technical-stories-we-dont-need-em/
http://stackoverflow.com/questions/1828057/system-stories-for-agile-architecture