Time boxing is about fixing the time we have available to work on a given task and then doing the best we can within that time frame. So instead working on something until it is “done” in onesitting, we only work on it for say 30 mins. It is either marked as done at the end of this period or we commit to another 30 mins at a later time or another day. In software development, an agile team releases new versions of a product to the customer for testing in fixed length iterations, say weekly. The customer and the development team work together to identify the features to be included in each release based on the relative priority and complexity of each task. Time boxing一種管理方法，即在預算時間內對完不成的功能進行刪減或者延遲，而不是拖延預算的時間。用我們熟悉的術語就是“後牆不倒”。 一個“Time box”是一個比較短而且固定長度的時間段。在這個時間段中，團隊成員要為滿足一個特定的目標做出努力。這個目標可以是一批功能需求或技術需求，也可以是滿足一個釋出目標（例如，beta測試應支援150個使用者），還可以是完成一個可執行的原型，等等。

時間盒的好處

《敏捷迭代開發——管理者指南》 研究表明在提高生產率方面，時間盒本身能帶來好處。

• 一個原因就是專注（focus）。Steve McConnell總結得最好：“你在度假的前一天做完工作，這是一件多麼了不起的事情。”心理學認為安排結束日期為三週之後，比在三個月之後設立可視的里程碑，專注的效果更好。時間盒被視為是帕金森定律（Parkinson’s Law）的一劑良藥：“如何開展工作？只要有效地填滿完成前的這段時間。”
• 無論是迭代，還是整個專案，時間盒的另一個價值來自人類的一個怪癖：人們往往記住失誤的日期，而不是失誤的特徵。如果將一個專案延遲3個月，得到100%所期望的特徵集，那麼，人們會認為這是一個“失敗”的專案。假如按時交付具有75%最重要特徵的產品，那麼會被認為是一個成功的專案。
• 另一個原因是要求我們處理小級別的複雜度。通過為期兩週的小型時間盒迭代，團隊承擔的是可管理的複雜度，做他們力所能及的工作，同時在可能突破最後期限內的情形下，他們有能力縮小工作範圍。資料表明，低複雜度的步驟能夠提高生產率。
• 時間盒還有一個更為微妙的好處就是：儘早促成難度大的決策和權衡。例如，在一個Scrum專案中，你受限於30日的時間盒迭代。在迭代計劃會議上，團隊將非常現實地考慮哪些工作將納入迭代中，哪些將推遲。由於向客戶的演示正好是30天，因而對短期目標和優先順序不能含糊不清。利益相關人員也被迫儘早嚴肅地考慮優先順序。

其他來源中的總結：

· 時間盒將混沌框在一處，使大家能夠完全聚焦於滿足達到成功所必須的最小需求。 · 更好的控制：時間盒是一個以時間盒結束點的決定為標記的短期投資。它使得專案在走得過深而不受控之前，讓風險得到更多的最小化機會。頻繁的決定使客戶(business owner)來控制預算和質量。讓Surprises 最小化。 · 因為時間盒很短，所以沒有多少空間來追求完美或鍍金（如加入不十分必要的特性），或為潛在的目的而過分的質量要求。 · 由於時間短，它可以更快的反映失敗或更早提供價值。更早提供價值，也就意味著生產出了有用的東西（例如：一個可以工作的模組、一組功能的部署、滿足一個技術需求等等）。 · 更快的反映失敗，使你更快地知道你是否能達到目標，滿足需求。換句話說，如果你不知道何去何從，你可以更快地回到起點，嘗試其它的途徑。 · 由於時間盒是以結果為匯入的且需要頻繁做出決定，所以它是極限專案管理中面對不確定性而保持受控的最重要的技術之一。

使用方法

Time boxing是基於實際生產率的，而不是估算，即那些我們認為我們應該完成的工作。 · 預算需求 · 進度 · 技術需求 · 質量需求 · 範圍需求 · 必需的技術力量（質量及數量） · 客戶滿意度 · 團隊滿意度 由於Time box由以下內容構成：以具體的目標為導向做事情，決策者有權根據上面的列表內容的任何變化做出決定，並以事實為依據做事，而不是依據推測做事。在這一點上， “Time box是剔除不確定性的一個工具”。而且，與傳統的專案管理理念（計劃驅動結果）相反，極限專案管理是以Time box中應得到的結果進行計劃定製。

定製時間盒的過程（The Time boxing Process）

時間盒在推測週期（Speculate Cycle）中被識別，並在創新週期（Innovate Cycle）中被實現。時間盒的定義可以被總結為以下三步：計劃(Plan)、執行(Do)和複查(Review) 1、計劃(Plan)－－這包括對時間盒的預期產出達成一致，花費多少能達到目標（時間盒的長度、對於技能的要求、預算等），以及度量成功的標準是什麼。作為一個指導原則，一般來說，這一步大約需要時間盒的15%。 2、執行(DO)－－這意味著做實際的工作去完成目標，生產計劃中的預期產出。這一步大約點時間盒的70%。 3、複查(Review)－－這一步包括總結學到了什麼，建議或決定下一個時間盒向哪個方向走。

制定時間盒的規則

· 固定時間盒的長度（一般為幾天，最高為六個星期） · 全生命週期質量是極限專案管理的十大共享價值之一。即一個時間盒應該基於40小時/星期這個工作時間進行計劃。 · 在每個時間盒過程中，不要增加人員。牢記Brook的理論：在一個滯後的專案中加人只能使其更滯後。 · 時間盒的結束日期不可變更。應該在有效的時間裡做你能做到的事情，然後再重新組合(re-group)。 · 時間盒不是用來做績效考核的。極限專案要處理很多未知內容。如果盡最大努力之後，你還沒有滿足時間盒的要求，你要重組並做出新的決定，決定如何做才能最好的向前推進。 · 如果在時間盒期間需要追加需求，那麼原來時間盒中的某些任務必須放到以後的時間盒中。如果有重大變化發生的話，應取消時間盒，重新計劃並執行新的時間盒。 · 每日同步。 · 擁抱改變並不意味著混沌，在持續不斷的變動之海中，必須有一個穩定的點。因此，我們必須遵守在迭代與漸增開發方法中的一個規則：一旦某個反覆正在進行當中，外部的 stakeholder 不能改變這個反覆中的工作內容。Time-Boxing 的用意在於緩衝、在於控制風險，不讓整個開發過程中因為無窮止的不斷地改變而造成混亂而失去控制，但它更不是拒絕改變或是凍結需求，而是讓開發者集中心力把焦點放在最關鍵或最優先的問題上。換句話說，在開發過程中，Time-Boxing 可限制變動只會發生在一定的範圍中，而不讓變動太過激烈而造成開發團隊的崩解，或是尋求靜態平衡而造成一片死寂，它所追求的是處於混沌邊緣的動態平衡，使系統富有足夠的穩定與彈性。