用戶故事自最早1998年誕生以來，由於其突出的優點，到現在得到了廣泛的應用。從最開始的克萊斯勒C3項目，用戶故事當中的用戶一般是指軟件系統的人類用戶，這類用戶故事一般涉及人機交互界面。
而隨着用戶故事在多種場合擴展使用，慢慢衍生出另外兩類故事。本文試圖來整理下新的故事。
新的故事
1，系統故事 System Story
2，賦能故事 Enabler Story，也稱推動者故事，或者使能故事
爲什麼不用技術故事
技術故事，技術一詞，含義廣泛，因此技術故事有不同的理解。
常見的例子有：
- 重構某個故事；
- 非人類的系統擔當交互對象；
- 建設技術債務觀測工具；
- 對某關鍵模塊進行架構設計。
幾乎除了用戶故事之外的故事，都曾經被人稱爲技術故事，所以技術故事成爲了一個含義廣泛的詞語。
系統故事
系統故事是指系統或者組件之間發生的交互。另外一個角度可以理解爲非人類用戶故事，與用例分析當中的非人類角色是相當的情況。
對於複雜組合大應用，中間系統往往並不與人類用戶直接交互，往往是與其它系統進行交互。而當前不少組織的分工是安裝系統或者模塊來劃分的，不少組織當中的團隊所處理的系統或者模塊無論位於何處，都有與其它系統或者模塊的交互。這時如果不能快速的重組團隊，也就是團隊所負責的範圍沒有變化的話，那麼系統故事就是無奈的、必需的選擇。
一般的，系統故事所描述的仍然是系統的功能，當然有些情況下深入到系統內部的組件級別，這時描述的是系統內部的功能。
賦能故事
賦能故事，不是用來描述系統功能的，而是用來建設更好的開發測試方法、環境、架構、基礎設施等等。
其小類有：
- 改進故事
- 環境建設故事
- 測試準備故事
- 設計架構故事
- 其它
識別多種類型故事的原因
有不少人認爲沒有必要識別其它類型故事，因爲其它事務可以以任務的形態進入到迭代計劃。
那麼原因就是在迭代計劃當中，主要有如下2點：
- 從思考的角度講，用戶故事和任務是兩個層次的事物，對於不同層次的事物對於工作量和優先級的思考是頗有麻煩的；
- 在電子工具使用的情況下，對於不同類型的條目難以混排在一起。當前流行的Rally和Jira缺省都是按故事來進入到迭代的backlog。
而識別了多種類型故事後，有如下好處：
- 開發測試系統本身的事物，以及輔助開發測試的事物，所有團隊需要處理的事物放在相同層面，同場競技，能夠更好的全面考慮各類事物的優先級和安排；
- 故事點估算可以跨越不同類型事物，通過故事點可能更好的計劃迭代，故事點超越了傳統的用例點、功能點等等的範圍；
- 絕大多數支持敏捷的電子工具都能管理單一層面的故事優先級排定。
參考
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
