一、根據發布目標分析需求，把需求分析成獨立的故事，初步的分析可以是粗略的，隨著需求的不斷深入刻意對故事進行整合或者切割。
要注意的是分析出來的需求盡量在發布目標的范圍之內，超出發布目標的需求應該盡量避免過深分析。
所謂的發布目標是確定了這個版本可以讓用戶滿意的條件。
故事模式：做為（用戶角色），我可以（做什么），以便（業務價值）。后面的業務價值在比較簡單或者大家都比較明確的時候刻意不需要注明。
當前團隊實踐推行方法：
第一階段，這個分析工作開始由PM進行收集、整理和分析。
第二階段，當大家都為用戶故事的方式接受以后，采用需求討論的方式來明確和分析用戶故事。
二、對分析的故事進行相對估計，估計出來的故事點是對用戶故事和復雜度的無單位估計值，使用的數值大小本身沒有絕對意義，只有相對于其他故事規模的相對意義。
比如，用戶登錄這個用戶故事的估計值是2，那么做為同等開發規模的用戶推出，這個用戶故事的估計只也應該是2。
當前團隊實踐推行方法：
第一階段，這個估計的工作暫時由PM來負責完成，但是由于一個人的估計肯定會有偏差，所以在估計完成之后需要進行調查來進行修正。
第二階段，用估計撲克會議來統一的對用戶故事進行估計，當主持人拿出一個新的用戶故事之后，大家給出自己對這個故事使用撲克打分，然后取出平均值，對差異較大的估計值要給出解釋，來消除對用戶故事的錯誤理解。估計撲克會議的實踐不超過１個小時。
三、準備產品調查，對用戶故事進行功能存在，和功能缺失性的產品調查，然后根據調查結果對用戶故事進行劃分，劃分成3類：基本需求，線性需求，非線性需求。
此外還有反對的需求、存在疑問的需求、無所謂的需求3種類型的需求，這些需求將根據進一步的發展進行確認。
當前團隊的實踐推行辦法：
第一階段，由PM發出調查問卷在參與到項目的開發團隊、測試團隊、技術支持團隊來進行調查，然后匯總答案根據存在問題和缺失問題的答案，對用戶故事進行定性。
第二階段，由PM發出調查問卷擴展到相關的用戶群體中進行調查，然后匯總答案根據存在問題和缺失問題的答案，對用戶故事進行定性。
四、確定發布規劃，首先要確定的是迭代周期的長度，以周為單位，然后估計出每個迭代周期團隊的速度。然后可以從用戶故事池中選擇出合適的用戶故事來填充到第一次和第二次的迭代周期中。其余的暫時可以先不用填充，隨著每次迭代周期的完成來對發布計劃進行更新。最后根據估計的速度和需要開發的故事來確定需要幾個迭代周期，并最終有幾個迭代周期來確定需要開發的時間周期。發布計劃可以以功能來驅動進行，也可以以日期來驅動進行。
發布規劃的特點，以月做為時間范圍，規劃對象是用戶故事，估計的單位是故事點。
文章來源于領測軟件測試網 http://www.kjueaiud.com/