傳統的瀑布工作模式使用詳細的需求說明書來表達需求，需求人員負責做需求調研，根據調研情況編制詳細的需求說明書，進行需求評審，評審之後簽字確認交給研發團隊設計開發。在這樣的環境下，需求文件是資訊傳遞的主體，也是乙份契約。
然而詳細的需求說明書有以下5大弊端：
敏捷使用產品backlog來管理需求，產品backlog是乙個需求的清單，按照需求的商業價值排序， 高優先順序的需求在backlog的最上層。產品backlog是乙個漸進明細的清單，它有4個主要特點，稱之為deep：
在產品backlog中，需求的主要表現形式是使用者故事。使用者故事是從使用者的角度對需求的簡短描述。使用者故事是將團隊的焦點從描述、編寫功能需求轉移到討論需求的最佳方式。
使用者故事是從使用者的角度來描述使用者渴望得到的功能。乙個好的使用者故事包括三個要素：
使用者故事通常按照如下的格式來表達：
英文：as a , i want to , so that .
我們目前是用的國內的一款敏捷工具leangoo在做需求管理！leangoo是乙個非常簡潔的看板協作工具，我們可以通過leangoo建立產品backlog看板來管理敏捷需求。通過leangoo看板對產品backlog條目進行視覺化管理，讓整個團隊非常直觀的了解需求的優先順序和規劃安排。
下圖就是乙個產品backlog看板的示例：
在leangoo看板上，我們可以建立多個列表，然後在每個列表上新增故事卡片。
因為我們需要將近期高優先順序的需求放到sprint中，所以在看板上可以建立這幾個列表：待整理原始需求，以後的迭代，下個迭代待梳理故事，下個迭代就緒故事，當前迭代，已交付。
我們可以根據需求的優先順序把需求分別放到這幾個列中。當前迭代的優先順序最高。
建立好了列之後，我們就可以往列表裡面增加卡片了，每個故事一張卡。我們可以為每一張卡片新增工作量，以及故事的驗收測試要點。驗收測試要點以檢查項的方式體現。
我們也可以為卡片設定標籤標籤通常是用來給卡片分類，也可以用卡片標註優先順序！（每張卡片的優先順序可以位置來決定的，每個list裡面的卡片根據位置對卡片進行強制排序，高優先順序的卡片放到最上面，低優先順序的需求卡片在下面）
卡片id我們也可以為每一張卡片設定id,便於卡片定位溝通和跟蹤，在選單欄開啟就可以。卡片多選當我們開啟卡片多選的時候 可以批量移動卡片，為卡片批量新增標籤，為卡片批量新增成員等等 ，這也是我最愛的功能之一燃盡圖當乙個迭代結束時，我們要對完成的故事進行評審會議，評審通過的故事可以挪到已交付的列表中。leangoo會根據故事卡的變化自動生成發布燃盡圖，點選選單-看板統計，就可以檢視！不僅有燃盡圖 還有任務週期，任務分布等
如下圖所示：
通過上述的方式，我們就可以很好的管理我們的產品backlog了。
最後還有一點提醒，敏捷強調透明性，所以，視覺化管理產品backlog很重要，如果條件允許，我們可以考慮通過大的顯示螢幕將產品backlog進行視覺化，有觸屏大電視會更好。
產品經理必讀 敏捷開發中的需求管理過程全解
產品的源頭是需求。一切偉大產品的實現都是從需求管理開始的。敏捷開發中的需求管理大致分為三個階段 需求調研，需求分析和需求確認 需求調研階段 產品立項後，產品經理便開始了和需求打交道的漫長過程。第一步就是需求的調研工作。需求調研的質量，會直接影響到後續產品設計的工作。產品經理可以從以下渠道來調研需求 ...
產品思維學習 五 產品敏捷開發和專案管理
一般產品人員進行過需求採集，分析，篩選後就會進行產品的設計。在產品設計的過程中會產生prd product requirement document 產品需求文件 如果是新產品或者在大公司一般還會有brd business requirement document 商業需求文件 和mrd marke...
敏捷開發每日一貼 需求管理和例項化需求
需求管理和例項化需求 軟體開發的最大問題之一往往是需求，而且它也很容易的被作為替罪羊。在公司專案延遲和出大問題的最大藉口，就是 需求不清楚 需求變更 那把需求早點弄清楚不就行了嘛？聽著挺容易，但要做好它卻很困難。敏捷迭代起來以後是否會好點呢？理論上會好點，因為需求在乙個迭代中東西會少點，更容易理清楚...