敏捷計劃的目的是以迭代的方式為產品開發的綜合問題，在那段時間內使用那些資源來得到哪些功能，去尋找到最佳解決方案。敏捷估算和計劃方法可以成功找到這樣的解決方案的原因包括：計劃是在不同層次上作出的，并且頻繁的重新計劃；計劃是根據特性而不是根據任務作出的；首先估算大小，然后根據大小的估算值推算出持續時間；小故事保持工作的流動，而且每次迭代結束時會消除未完成的工作；在團隊層次而不是個人層次對進度進行度量；承認不確定性并為之做計劃。
敏捷估算和計劃價值分析：
無論軟件開發項目的規模如何，估算和計劃對于項目的成功都是至關重要的。估算與計劃并不僅僅是決定一個恰當的最終期限和進度表，而是對價值的探求.
1.減少風險
2.降低不確定性
3.提供更好的決策支持
4.建立客戶信任
5.傳遞信息
計劃失敗原因分析：
1.基于活動而不是基于特性進行計劃：基于活動的計劃常導致項目實際開發超出計劃表，有些團隊會試圖通過不恰當地降低質量來節省時間，有些團隊會制定變更控制策略來限制產品變更。主要因素包含：活動不會提前完成；延誤隨進度表傳遞；活動不是互相獨立的。
2.多任務處理導致更多的延遲：同時處理多個任務，多任務會對生產效率產生可怕的影響。當項目中開始有些活動被延期的時候，多任務處理往往變成了問題。
3.不按優先級開發特性：不按照特性的優先級順序進行開發，因此某些被放棄的特性可能反而比所交付的特性更具有價值。
4.忽視了不確定性：忽視了與產品相關的不確定性，比如我們不能指望一開始就確定項目進程中需要的所有活動，但我們制定的計劃中往往無法意識到這一點。應對不確定性的最佳方法是迭代。
5.把估算當作承諾：如果項目團隊或者利益干系人把估算當作了承諾，傳統的計劃方法就會出現問題。在做出這樣的承諾之前，團隊需要對大量的商業因素和風險進行評估，并且不要把所有的估算都當成是隱性的承諾。
如何估算大小：
兩種度量大小的方法：故事點和理想時間。
故事點：故事點是對用戶故事大小的相對度量，將要進行的工作大小進行估算，項目的持續時間通過求取項目的總故事點數，再除以小組的速度而推算出來的.
理想時間：理想時間不是耗用時間，使用理想人天估算，就只需考慮完成這個用戶故事所需要的時間，最好只為每個用戶故事分配單一的估算值。應該把所有需要的時間加在一起，說某個用戶故事需要九個理想人天，而不是說他需要四個程序員人天、兩個測試人員人天和三個產品負責者人天。
在故事點和理想人天之間進行選擇：
故事點的優勢是可以幫助促進團隊的跨功能行為。此外，由于故事點是更為純粹的對大小的估算，因此即使團隊在技術上或是領域知識上取得了進步，也并不需要重估他們。如果一個團隊成員認為某件事情需要4個理想人天，而另一個成員認為只需要1個理想人天，也許他們都是對的，但是他們缺乏討論的共同基礎，無法建立一個單一的估算值。
理想人天的優勢在于更容易向團隊之外的人進行解釋，以及更容易開始。
我的傾向是使用故事點。使用故事點進行估算的優點更有說服力。如果團隊對單純的大小進行估算存在困難，可以讓他們用一下人天開始估算，然后再讓他們轉化到故事點上。更多的問“這個功能的大小與我們剛才估算的那個相比怎么樣？”而不是去問“它會需要多少個零小人天？”大部分團隊幾乎不會注意到這種漸進式的轉變，而當他們意識到的時候，他們已經是在用故事點而不是理想人天進行思考了。
估算方法：
四種最常用的估算方法是：
專家意見：如果你想知道一件事需要多長時間，去問問專家。在基于專家意見的估算方法中，專家根據他自己的直覺給出估算。根據專家意見進行評估的一個好處在于他通常不需要太長時間。根據專家意見進行評估的一個好處在于他通常不需要太長時間。
類比：當用這種方式估算時，你不必把所有用戶故事都按一個基線或是通用的參照物進行比較，而是把每個新的用戶故事與那些已經估算過的用戶故事進行比較。這稱為三角測量。
分解：分解是指將一個用戶故事或者特性分解為更小、更容易估算的部分。不過當分解太過時，不僅忘記某項任務的可能性會增加，而且對于大量小任務都估算值求和也會出現問題。
計劃撲克：要得到一個估算值，我們除了可以依賴專家意見、類比和分解，還可以依賴計劃撲克。計劃撲克是一個有趣而有效的方法，它結合了上述三種方法。在計劃撲克中，每個估算者有一疊寫著有效估算值的卡片。每討論一個功能，每個估算者就選擇一張代表他的估算值的卡片。所有的卡片都會同時展示出來。團隊對估算值進行討論，重復這個過程直到團隊的估算達成一致。
不確定因素如何處理：
大多數項目都包含大量的不確定性。項目團隊建立的進度表和最后期限中往往沒有完全反映這種不確定性。有些時候，如果這種不確定性非常大或者非常顯著，就需要在估算項目持續時間的時候采取一些額外的步驟。這些情況可能包括：提前很早就進行項目計劃、項目必須絕對滿足最后期限（同時交付一組相當嚴格的功能集）、項目是外包的、需求人員處于非常表面的層次、或者在日期出錯時會產生嚴重的影響（經濟或其他方面）等。
特性緩沖區和進度緩沖區是兩類最常見的緩沖區。當團隊確定了項目中所有需求的優先級，而且發現可能無法交付所有功能的時候，就需要建立一個特性緩沖區。另一方面，團隊可以在進度表中包含一定量的時間來建立進度緩沖區，這個時間的量反映了蘊含在項目規模中的不確定性。團隊可以通過同時估算每個用戶故事具有50%的概率的大小和具有90%的概率的大小來構造進度緩沖區。通過對每隊50%和90%估算值采用平方和和平方根的公式，可以估算出合適的進度緩沖區大小。
項目應該用特性緩沖區來預防特性不確定性，用進度緩沖區來預防進度不確定性。可以把特性緩沖區和進度緩沖區結合起來。實際上，這常常是個好方法，因為它可以讓每個緩沖區的規模都更小。
計劃多團隊項目：
敏捷開發項目傾向于在開發大型項目時避免使用大型開發團隊，而是使用多個團隊。當有多個團隊工作與一個項目時，他們就需要相互協調。
首先，團隊應該為他們的估算建立一個共同的基準。所有戰隊都應該同意按照相同的單位進行估算：要么是故事的，要么是理想人天。
其次，當多個團隊需要一起工作的時候，盡早給他們的用戶故事增加細節常常很有幫助。進行這一工作的最佳辦法是確認產品負責人對于用戶故事的滿意條件。滿意條件就是一旦故事完全實現了，就可以進行演示的那些細節。
第三，在發布計劃過程中結合一個滾動性前瞻計劃，可以讓多個團隊受益。滾動性前瞻計劃簡單地向前看幾次迭代（典型的是2～3次），通過共享在不久的將來每個團隊分別會處理那些工作的信息，讓團隊之間可以協調工作。
第四，在具有很多團隊間依賴性的高度復雜項目中，把饋送緩沖區結合到計劃中是很有意義的。饋送緩沖區是一段時間，可以避免由于一個團隊推遲交付而導致另一個團隊推遲啟動。
監督迭代計劃：
任務板：常常是一張白板、軟木板或者只是墻上特定的一片區域，可以幫助開發團隊組織他們的工作，并把它們可視化。任務版的各列都帶有標題，團隊成員根據工作進展把任務卡在個列間移動。
迭代燃盡圖：只是用來跟蹤當前迭代中的工作，它的縱軸是剩余工作的小時數，而橫軸是迭代中的天數。
團隊不應該計算或跟蹤個人速度。
