本系列的第一篇【用戶故事驅動的敏捷開發（規劃篇）】跟大家分享了如何使用用戶故事來幫助團隊創建需求的過程，在這一篇中，我們來看看如何使用這些用戶故事和功能點形成產品backlog。產品backlog是敏捷開發中用來管理需求列表，排定優先級，形成迭代計劃，組織開發/測試和交付過程的工具?？梢哉f，產品backlog是一個敏捷團隊管理開發過程的核心，所有的活動和交付物都圍繞backlog來進行。一旦需求明確，我們就必須在開發過程中持續的跟蹤backlog內容的實現和交付過程，確保我們的想法可以按照我們希望的時間和質量交付，及時了解偏差并做出調整。
　　從這個時間點開始，我們需要引入電子化工具來管理我們的開發過程。其實，每個開發團隊都會或多或少的使用某種電子化工具，用最多的估計是Word/Excel/Project這種辦公軟件，還有就是如Jira， Redmine， Bugzilla 等工具。對于軟件研發來說，我們需要管理內容包括：1）需求/任務/測試用例/Bug/問題等工作事項；2）源代碼；3）各種計劃，包括迭代計劃，發布計劃，測試計劃等；4）各種工件（包括：依賴包/在制品/交付物），如：JAR包，WAR包，NuGet包，NPM包，安裝包，交付包等；5）人員/團隊。所以，對于軟件研發管理系統來說，我們至少需要這些功能：1）工作項跟蹤；2）計劃制定和跟蹤；3）人員（包括權限）管理；4）源代碼管理；5）自動化引擎。
　　很多敏捷教練其實對電子化工具持保留態度，覺得電子化的backlog或者kanban等工具會影響團隊的參與感和靈活性。對這一點，我也同意，特別是在進行創造的過程中，我也不贊成使用電子化工具。主要原因是創造的過程需要集思廣益，需要每個團隊成員都有參與感，需要每個人可以隨時對于用戶故事做出改變，這樣的過程如果使用電子化工具會很受限制。
　　但是，電子化工具仍然有其不可替代的用武之地，特別是我們需要進行持續的跟蹤和數據分析的時候，電子化工具就顯示出它的優勢；同時，如果你的團隊分布在不同的物理地點，那么使用電子化工具就成為一種必然。因為這些場景都是物理板無法發揮作用的時候。另外，考慮到軟件開發過程的復雜性和各個部分只見關聯性很強，如果沒有電子化工具的輔助，是很難支撐一個團隊的開發工作的。
　　在我帶領團隊使用用戶故事地圖的過程中，隨著用戶故事數量的增加，我發現團隊開始迷失功能點與故事之間關聯性，分解出來的功能點被淹沒在不同的模塊之中了，用戶故事已經開始慢慢消失了。這是個非常不好兆頭，所以我在這個時候開始要求團隊引入電子化工具。
　　樣例程序和用戶故事列表
　　為了能夠更好的說明這個過程，在這個系列中我使用【鳳凰項目：一個IT運維的傳奇故事】這本書為背景的ASP.NET 5樣例應用，創建了一些用戶故事。
　　關于【鳳凰項目：一個IT運維的傳奇故事】：本書講述了一位IT經理臨危受命，在未來董事的幫助和自己“三步工作法”理念的支撐下，最終挽救了一家具有悠久歷史的汽車配件制造商的故事。 小說揭示了管理現代IT組織與管理傳統工廠的共通之處，讓讀者不僅能對如何管理IT組織心領神會，更重要的是將以完全不同于以往的視角看待自己的工作環境。 可以通過以下鏈接購買這本書的中版：http://item.jd.com/10034038960.html
　　這個樣例應用可以通過以下地址訪問：http://pucd.chinacloudsites.cn/
　　
　　這是一個簡單的電子商務網站原型，具備產品列表，購物車，后臺管理，促銷和訂單處理等電子商務網站的基本功能。你可以瀏覽一下這個網站，對其中的功能簡單了解一下。