傳統的瀑布工作模式使用詳細的需求說明書來表達需求，需求人員負責做需求調研，根據調研情況編制詳細的需求說明書，進行需求評審，評審之后簽字確認交給研發團隊設計開發。在這樣的環境下，需求文檔是信息傳遞的主體，也是一份契約。
然而詳細的需求說明書有以下5大弊端：
- 單向的信息傳遞，容易出現理解偏差。
- 文檔很正式，我們會誤以為它一定是對的，不去質疑它，讓我們停止作出判斷。
- 有了詳細的文檔，我們不會反復討論它，相互確認。
- 書面文檔不利於團隊共享責任，它扮演了證據的角色。Scrum強調團隊共享責任，不論是需求人員、開發人員和還是測試員，大家的共同目標是通過討論、協作，正確理解需求之后把這些需求變成客戶真正需要的功能，而不是單向的任務傳遞。
- 編制詳細的、表達准確需求文檔需要花費大量的時間，如果需求變化頻繁，維護成本更高。
敏捷使用產品Backlog來管理需求，產品Backlog是一個需求的清單，按照需求的商業價值排序， 高優先級的需求在Backlog的最上層。產品Backlog是一個漸進明細的清單，它有4個主要特點，稱之為DEEP：
- Detailed 合適的詳細程度，高優先級需求更加明細，低優先級的需求粒度更大
- Emergent 涌現式的，需求是慢慢涌現出來的，漸進明細的
- Estimated 經過估算的
- Prioritized/ Ordered 根據商業價值排好順序的
在產品Backlog中，需求的主要表現形式是用戶故事。用戶故事是從用戶的角度對需求的簡短描述。用戶故事是將團隊的焦點從描述、編寫功能需求轉移到討論需求的最佳方式。
用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：
- 角色：誰要使用這個功能。
- 活動：需要完成什么樣的功能。
- 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。
用戶故事通常按照如下的格式來表達：
英文：
As a <Role>, I want to <Activity>, so that <Business Value>.
中文：
作為一個<角色>, 我想要<活動>, 以便於<商業價值>。
比如：作為一個網站的普通會員，我期望在我下訂單后，未發貨之前可以取消訂單，這樣對我來說更靈活。
我們目前是用的國內的一款敏捷工具Leangoo在做需求管理！
Leangoo是一個非常簡潔的看板協作工具，我們可以通過Leangoo創建產品Backlog看板來管理敏捷需求。通過leangoo看板對產品backlog條目進行可視化管理，讓整個團隊非常直觀的了解需求的優先級和規划安排。
下圖就是一個產品Backlog看板的示例：
在Leangoo看板上，我們可以創建多個列表，然后在每個列表上添加故事卡片。
因為我們需要將近期高優先級的需求放到Sprint中，所以在看板上可以創建這幾個列表：待整理原始需求，以后的迭代，下個迭代待梳理故事，下個迭代就緒故事，當前迭代，已交付。
我們可以根據需求的優先級把需求分別放到這幾個列中。當前迭代的優先級最高。
建立好了列之后，我們就可以往列表里面增加卡片了，每個故事一張卡。
我們可以為每一張卡片添加工作量，以及故事的驗收測試要點。驗收測試要點以檢查項的方式體現。
除了工作量，檢查項，我們可以對這個故事進行一些討論，也就是評論，也可以@某位成員！
我們也可以為卡片設置標簽
標簽通常是用來給卡片分類，也可以用卡片標注優先級！
（每張卡片的優先級可以位置來決定的，每個list里面的卡片根據位置對卡片進行強制排序，高優先級的卡片放到最上面，低優先級的需求卡片在下面）
卡片ID
我們也可以為每一張卡片設置ID,便於卡片定位溝通和跟蹤，在菜單欄開啟就可以。
卡片多選
當我們開啟卡片多選的時候 可以批量移動卡片，為卡片批量添加標簽，為卡片批量添加成員等等 ，這也是我最愛的功能之一
燃盡圖
當一個迭代結束時，我們要對完成的故事進行評審會議，評審通過的故事可以挪到已交付的列表中。
Leangoo會根據故事卡的變化自動生成發布燃盡圖，點擊菜單-看板統計，就可以查看！不僅有燃盡圖 還有任務周期，任務分布等
如下圖所示：
通過上述的方式，我們就可以很好的管理我們的產品Backlog了。
最后還有一點提醒，敏捷強調透明性，所以，可視化管理產品backlog很重要，如果條件允許，我們可以考慮通過大的顯示屏幕將產品Backlog進行可視化，有觸屏大電視會更好。