在計劃發佈時，有必要知道客戶預期的大致發佈日期和故事的相對優先級；
故事應該以明確順序排列，第一個、第二個…而不是利用諸如“非常高、高、中等”的分組；
迭代計劃是發佈計劃的進一步計劃，但只是在迭代即將開始時纔開始做迭代計劃。
-迭代計劃會議的一般內容：
討論故事；
從故事中分解出任務；
開發人員承擔每個任務的職責；
討論過所有故事，並且接受所有任務後，開發人員單獨估計他們承擔的任務，以確保他們不會做出樂觀承諾。
迭代燃盡圖展示了用完成的故事點表示的進度和剩餘故事的改變。
爲每輪迭代計劃和實際完成的故事點數畫圖是檢測實際和計劃速率區別的好方法。
累計故事點圖可以反映每輪迭代中完成的故事點。
每日燃盡圖展示迭代中每天剩餘的小時數。
-用戶故事不良症兆（smell）：
故事太小；
故事互相依賴；
鍍金（開發人員主動去增加的客戶沒有要求的功能）；
細節太多；
過早考慮用戶界面的細節；
想得太遠；（利用用戶故事的關鍵在於承認實現不可能發現所有需求，好的軟件是在不斷的迭代中發展而來，而在每輪迭代中都會發現新的細節需求，然後被添加到軟件。）
故事劃分太過頻繁；
很難爲故事安排優先級；
客戶不願意寫用戶故事，爲故事安排優先級；