準確地評估實現某種功能所需的軟件編寫工作量是一門藝術，但我們試圖通過敏捷實踐將其轉化爲一門科學。
實施敏捷的方法有很多：即預測變化、分解工作以及保持業務與開發人員的密切合作。團隊經常使用虛構的指標，比如“故事點”來衡量並不斷提高衝刺的可預測性和生產力。
請注意，故事點是一個虛構的指標——它們是不基於任何硬指標，如編寫的代碼行數——因此它們不能在公司或團隊之間轉移（多說一句，編寫出的代碼行數是一個可怕的指標，你永遠不應該在意這個指標，因爲對於好的代碼來說，行數越少越好）。
我們應該觀察伴隨着時間的推移，每個團隊是否在達成其故事點方面是否變得更有效率。
一切皆需有度：我們並不嚴格遵循某個特定的敏捷方法論。我們允許團隊選擇他們自己的工作風格，有些團隊採用更正式的敏捷元素，另一些團隊則不太遵循敏捷原則。一旦架構已經確立，我們通常會讓團隊選擇他們的工作方式。