我們看到許多關於軟體流程、設計實務等充滿情緒的討論。其中許多爭論無法解決，因為軟體產業缺乏衡量軟體開發效能基本要素的能力。特別是，我們沒有合理衡量生產力的方法。

你無法把十磅的屎塞進五磅的袋子裡

-- 任何嘗試過的人

當 Kent 和我撰寫《規劃極限程式設計》時，我們加入了這句異想天開的引言，幫助大家了解規劃的精髓。

許多人認為，你無法在敏捷專案中採用固定價格合約。由於敏捷流程的重點在於無法預測未來，因此這並非不合理的假設。然而，這並不表示你無法提出敏捷的固定價格合約，真正的意思是，你無法提出固定範圍的合約。

許多公司喜歡撰寫固定範圍和價格的合約，因為他們認為這能降低風險。幻象表示他們的財務義務固定在合約價格。如果他們沒有得到滿意的軟體，那麼他們就不必付費。

理想時間是早期極限編程中用來協助估算工作量的術語。現在它大部分已被故事點或故事計數取代。

我第一次接觸敏捷軟體開發是在極限編程的黎明時期與 Kent Beck 合作。那個專案中讓我印象深刻的事情之一就是我們規劃的方式。這包括一種估算方法，既輕量又比我之前見過的更有效。現在已經過了十多年，現在有經驗的敏捷主義者之間爭論估算是否值得進行，甚至是否積極有害。我認為要回答這個問題，我們必須了解估算將用於什麼目的。

使用時間盒迭代的常見方法是將盡可能多的使用者故事分配到每個迭代，以最大化所涉及人員的利用率。鬆弛是一種故意留出未分配給故事的時間的政策，使用該時間進行非計畫工作。儘管這看起來效率低下，但通常會顯著提高團隊的生產力。

我最近聽過幾個問題，關於為使用極限編程規劃方法的多個團隊提出一個標準故事點機制。希望是讓多個團隊都使用等效的故事點，這樣一個團隊的三個故事點工作量與另一個團隊的三個故事點工作量相同。

我認為盡力想出這個方法，最好的情況是價值有限，最壞的情況是危險的。

故事計數是規劃和估算的技術。類似於 故事點，它與 XpVelocity 合作，協助您找出在固定時間內可以傳遞多少個故事。然而，它的不同之處在於，您只考慮每單位時間的故事數量，而且（大多數情況下）忽略它們的相對大小。

故事點是敏捷專案中故事大小的常見名稱。與 XpVelocity 結合使用時，它們提供一種技術來協助規劃，方法是提供故事何時可以完成的預測。

如果您使用 XP 風格規劃，您需要從開發人員那裡取得快速共識估計。拋出估計讓您可以快速得知開發人員對估計的看法是否類似（這樣您就可以記錄下來並繼續進行），或者是否有分歧（當您需要更詳細地討論 使用者故事 時）。

速度是一個有助於校準計畫的概念，它將廣泛的努力陳述與經過時間聯繫起來。速度是團隊（或個人，如果是個人速度）在一段時間內完成多少工作的陳述。您通常應該透過衡量過去期間完成的工作量來確定速度，遵循 昨日天氣 的原則。一種典型的方法是平均過去三個時間段的速度，以確定未來時間段的速度。速度最初是作為 極限編程 的一部分形成的，但後來已經廣泛傳播，現在被廣泛用於各種風味的 敏捷軟體開發 中。

這是一個原則，它表示您今天完成的工作量與昨天完成的一樣多。在反覆專案中，它表示您應該計畫在此反覆運算中完成與上次反覆運算中一樣多的工作。這個術語來自極限編程社群。