敏捷專案管理是以迭代和功能為推動力的。功能的推動性表現在它將計劃和執行的主要重點從任務轉變為產品功能。這是與傳統專案管理以任務為推動力的重要一個區別。我們將整個需求分解為細粒度的多個功能點，只有每個功能點的開發與測試全部完成才對進度貢獻和客戶承諾有意義。這與掙值中的0-100法則是相吻合的。 按需求和功能點進行WBS分解可能更難於管理，但是它跟開發人員的實際工作方式根據容易匹配，讓項目的工作和與客戶承諾保持同步。對於使用者來講只有真正可以交付的最終功能才是有價值的，而每一次迭代可以是一次交付，是對客戶承諾和價值實現的具體體現。 迭代周期的長短是我項目周期和項目對進度偏差限制密切相關的。一般而言在項目周期的15%左右處都應該設定相應的檢查點或裡程碑。以方便我們及早的發現進度的偏差和資源使用方式，並對反覆項目計劃進行適當的調整。同時裡程碑點也可能是項目同步和整合的關鍵點，在裡程碑點需要對各迭代功能進行整合并向使用者交付。 反覆項目計劃和裡程碑的安排必須考慮客戶價值和風險兩個要素。迭代的目的就是要在降低風險的情況下盡量滿足客戶價值的實現。因此在迭代前期必須要考慮技術風險的減輕和應對方案，使風險明朗。同時要真正的做好需求分析和使用者調研，優先交付使用者最關注的功能點。 對於反覆項目計劃的安排，主要涉及到如下活動： 1.確定已知的風險對反覆項目計劃的影響。2.確定裡程碑和迭代周期。3.為每次迭代(或者裡程碑)制定方案。4.根據優先順序，資源，風險和依賴將功能卡分配為每次迭代。5.結合功能卡和停車場圖總結該計劃。6.根據人力資源可用性和工作量估算計劃初步的項目進度。7.必要時調整完成的計劃。 對於大型軟體應用程式可能包含成千上萬的功能，雖然Team Dev需要制定詳細的進度計劃，但是客戶和專案經理等往往需要一種粗粒度的方式進行管理。而以功能為推動力的開發方法依靠的是粒度功能等級，《功能驅動開發》一書的作者德盧卡推薦的是使用停車場圖來規劃和報告組件活動的進展。 停車場圖可以清楚的看到每個模組或功能的具體功能點數，完成的進度情況，是否延期和完成期限等重要訊息。停車場圖可以是迭代進度計劃的進一步細化，由於簡單直觀而更容易使用到進度的跟蹤和管理中。
客戶團隊只需要一起制定反覆項目計劃(迭代功能卡圖)，而將每個迭代裡面詳細的進度計劃(停車場圖)留給具體的Team Dev。這種兩級的規劃方法將給Team Dev更多的靈活性。即使是對於較小的項目，活動和功能的兩級法也可以協助團隊思考某個產品。
