一、根據發佈目標分析需求，把需求分析成獨立的故事，初步的分析可以是粗略的，隨着需求的不斷深入刻意對故事進行整合或者切割。
要注意的是分析出來的需求儘量在發佈目標的範圍之內，超出發佈目標的需求應該儘量避免過深分析。
所謂的發佈目標是確定了這個版本可以讓用戶滿意的條件。
故事模式：做爲（用戶角色），我可以（做什麼），以便（業務價值）。後面的業務價值在比較簡單或者大家都比較明確的時候刻意不需要註明。
當前團隊實踐推行方法：
第一階段,這個分析工作開始由PM進行收集，整理和分析。
第二階段,當大家都爲用戶故事的方式接受以後，採用需求討論的方式來明確和分析用戶故事。
二、對分析的故事進行相對估計，估計出來的故事點是對用戶故事和複雜度的無單位估計值，使用的數值大小本身沒有絕對意義，只有相對於其他故事規模的相對意義。
比如，用戶登錄這個用戶故事的估計值是2，那麼做爲同等開發規模的用戶推出，這個用戶故事的估計只也因該是2。
當前團隊實踐推行方法：
第一階段，這個估計的工作暫時由ｐｍ來負責完成，但是由於一個人的估計肯定會有偏差，所以在估計完成之後需要進行調查來進行修正
第二階段，用估計撲克會議來統一的對用戶故事進行估計，當主持人拿出一個新的用戶故事之後，大家給出自己對這個故事使用撲克打分，然後取出平均值，對差異較大的估計值要給出解釋，來消除對用戶故事的錯誤理解。估計撲克會議的實踐不超過１個小時。
三、準備產品調查，對用戶故事進行功能存在，和功能缺失性的產品調查，然後根據調查結果對用戶故事進行劃分，劃分成３類，基本需求，線性需求，線性需求。
此外還有反對的需求，存在疑問的需求，無所謂的需求３種類型的需求，這些需求將根據進一步的發展進行確認。
當前團隊的實踐推行辦法：
第一階段，由ｐｍ發出調查問卷在參與到項目的開發團隊，測試團隊，技術支持團隊來進行調查，然後彙總答案根據存在問題和缺失問題的答案，對用戶故事進行定性
第二階段，由ｐｍ發出調查問卷擴展到相關的用戶羣體中進行調查，然後彙總答案根據存在問題和缺失問題的答案，對用戶故事進行定性
四、
確定發佈規劃，首先要確定的是迭代週期的長度，以周爲單位，然後估計出每個迭代週期團隊的速度。然後可以從用戶故事池中選擇出合適的用戶故事來填充到第一
次和第二次的迭代週期中。其餘的暫時可以先不用填充，隨着每次迭代週期的完成來對發佈計劃進行更新。最後根據估計的速度和需要開發的故事來確定需要幾個迭
代週期，並最終有幾個迭代週期來確定需要開發的時間週期。發佈計劃可以以功能來驅動進行，也可以以日期來驅動進行。
發佈規劃的特點，以月做爲時間範圍，規劃對象是用戶故事，估計的單位是故事點
當前團隊的實踐推行辦法：
第一階段，使用1周做爲迭代週期，開始時團隊速度使用估計的方式做出簡單估計，根據每個週期結束後的團隊速度再進行發佈計劃的調成。迭代週期內用戶故事的完成暫時以開發完成做爲標準。
第二階段，使用2周做爲迭代週期，可以使用原有的歷史速度做爲團隊速度，多出的一週時間做爲測試修復時間，迭代週期內用戶故事的完成以測試完成，完整的功能提交做爲標準，並在開發過程中熟練使用單元測試來進行確保功能的完整完成。
五、確定迭代規劃，根據填充到迭代週期內的用戶故事來分解成工作任務，工作任務包括設計工作，不同層次的開發工作，調試工作和測試工作等等具體的任務，然後對任務進行估計，這時候估計的單位以理想工作小時做爲單位。比如，設計需要兩個人小時，開發持久層需要1個人小時，調試持久層需要半個人小時，開發業務層需要2個人小時，調試中間層需要1個小時等等。。。
然後根據每個故事的人小時和這個迭代週期內參與的人數，以及每個人所能參與的實際有效時間（注意有效時間約爲每天6小時，需要考慮到會議，討論，頭腦休息等非理想工作時間）來判斷這個迭代週期的填充是否足夠，如果不夠則再加入一個用戶故事，如果超出則移出一個用戶故事到下一個迭代週期中。
迭代規劃的特點，以周做爲時間範圍，規劃對象是工作任務，估計的單位是理想小時
當前團隊的實踐推行辦法：
第一階段，使用速度驅動的方法來進行迭代規劃，即確定了本次迭代的速度，然後選擇用戶故事擴展成任務，對任務進行估計。
第二階段，使用承諾驅動的方法來進行迭代規劃，即提出一個故事，把故事擴展成任務，對任務進行估計，讓小組承諾是否可以完成這個故事，如果可以在迭代週期內完成則加入這個故事，如果不能完成則推遲到下一個迭代走起。
六、迭代開始，在迭代開始時召開迭代啓動會，分配迭代週期內的用戶故事和工作任務到個人，每個工作任務必須精確到個人，同一個用戶故事的不同工作任務可以根據情況適當分配給不同的人來完成。
當前團隊的實踐推行辦法：
第一階段，任務分配給個人，通常一個故事的任務分配給同一個人。
第二階段，任務分配給結對，通常一個故事的任務分配給同一個結對。
七、迭代進行，每日早對昨日完成的工作任務和問題進行彙報，並且同時計劃今天需要完成的工作任務，對於迭代過程中的進度和問題進行及時的觀察和調整，要求每個人完成某個任務之後要及時的告知整個小組知道（qq羣的方式最爲快捷）。
當前團隊的實踐推行辦法：
第一階段，由pm及時地對當日工作進行詢問。並負責把遇到的問題跑出來進行解決。
第二階段，小組成員主動地對已經完成的任務進行彙報，並及時把自己遇到的問題拋出來。
八、迭代結束，確認本次迭代完成的用戶故事，對於完成一部分的用戶故事計算到下一次迭代中。並對本次迭代的過程資產進行總結，形成FAQ方式的文檔進行規整。
同時根據新的需求情況，資源情況，已完成功能的回饋，以及開發中遭遇的不確定性問題，對發佈規劃和迭代規劃作出調整。
當前團隊的實踐推行辦法：
第一階段，使用學習網站，或者博客等方式對經驗進行記錄。
第二階段，使用完善的skills對經驗進行記錄，可以方便的組織成培訓文檔，並方便的進行搜索，查找。
九、迭代測試，爲了保證用戶功能完整的提交，每個用戶故事開發完成之後都要對該用戶故事進行測試，然後在針對開發中出現的問題進行修復，以便完整的完成一個用戶故事。
第一階段：測試迭代週期和開發迭代週期分開。
每次迭代開始階段由ｐｍ告知開發組需要開發的和修復的的用戶故事，同時告知測試組本次迭代需要測試的故事，需要準備的故事，需要複測的故事。
並在分配任務時，把修復故事的工作規劃到本次迭代中來。
每次開發完成的用戶故事點算作本次迭代的速度
|
|
迭代１ |
迭代２ |
迭代３ |
迭代４ |
迭代５ |
|
測試 |
準備故事１，２ |
測試故事１，２ 準備故事３，４ |
測試故事３，４ 準備故事５，６ |
複測故事１，２ 測試故事５，６ 準備故事７，８ |
複測故事３，４ 測試故事７，８ 準備故事９，１０ |
|
開發 |
開發故事１，２ |
開發故事３，４ |
修復故事１，２ 開發故事５，６ |
修復故事３，４ 開發故事７，８ |
修復故事５，６ 開發故事９，１０ |
第二階段：測試迭代週期和開發迭代週期合併。
每次迭代開始階段由ｐｍ告知開發組需要開發的故事，同時這些故事也是測試組需要準備測試的故事。要求這些故事分解的工作任務中要包括測試工作和修復工作。
每次測試完成的用戶故事點算作本次迭代的速度
|
|
迭代Ｘ |
||
|
測試 |
準備故事１，２，３，４ |
測試故事１，２，３，４ |
複測故事１，２，３，４ |
|
開發 |
開發故事１，２，３，４ |
修復故事１，２，３，４ |
完成故事１，２，３，４ |
十、發佈結束，對本次發佈中完成的用戶故事進行會議總結：
１確定最終完成的用戶故事，以及花費的迭代週期
２通過計算得到一個團隊的人平均速度，這個速度做爲下次發佈規劃的參考
３分析哪些用戶故事的估計出現了失誤，以及出現失誤的原因是什麼。
４最初的發佈版本在市場上有了初步反饋信息之後，可以延長１個迭代週期用來做爲發佈版本的反饋收尾。