在製品與前置時間基本為線性關係，減少在製品數量就能減少前置時間。

利特爾法則（Little’s Law）作為一個非常樸素的原理，為看板方法奠定了一個理論基礎，看似簡單的公式背後卻有其複雜的一面。

一、利特爾法則

利特爾法則的公式是這樣的：

平均吞吐率=在製品數量/平均前置時間

舉個例子，假設你正在排隊買快餐，在你前面有19個人在排隊，你是第20個，已知收銀視窗每分鐘能處理一個人的點餐需求，求解你的等待時間。

如果你已經決定要排隊，並且站到了隊尾，那麼在製品數量就是20（個），平均吞吐率是1（人/分鐘）。
從你站到隊尾的時候開始，一直到你點完餐，這個時間就是你的“前置時間”。
即使我們沒有學習過利特爾法則，也可以輕易地算出來：

    1 = 20 / x
    x = 20（分鐘）

因為在一段時間之內，保持工作量飽滿的話，我們每天能做多少工作基本是一定的，所以吞吐率基本上不會發生太大變化。
如果這個時候我們想縮短平均前置時間，也就是等待的時間，利特爾法則告訴我們：可以通過減少在製品數量來達成這個目標。
在這個例子中，就是減少排隊者的數量。

這也很好理解，10個人的佇列和20個人的佇列，前者需要等待的時間會更短。 [1]

二、限制在製品的意義

如上面所說，在製品數量和前置時間是成正比的，縮短前置時間的最有效手段就是減少在製品數量。

前置時間的增長會導致交付週期變長，這一點基本毋庸置疑。

前置時間的增長會導致交付的可預測性下降，俗話說“夜長夢多”，長時間停留在某一個階段會帶來一些額外的風險。

如果我們的交付週期比需求變化週期更長，那麼會有更多的緊急任務，所以交付週期變長會導致更多的緊急任務。

如果我們管理不好緊急任務的插入，會增大我們的在製品數量。

如果交付團隊的可預測性很低的話，那麼會影響到IT研發組織和業務部門的信任關係，當業務部門無法預測一個需求提交給研發部門什麼時候能交付的時候，那麼唯一可行的手段就是一次性把要做的事情全部都壓給研發部門，直接增大了研發部門的在製品數量。

同時在製品數量的增長會帶來的另外一個後果就是故障發現得很晚，這一點在過去三四十年的軟體工程方法論中都得到了驗證。

發現的故障需要資源和時間來進行修復，帶來的就是在製品數量的上升和前置時間的增長。