一句話開場：「你為什麼總是對 spill-over 這麼執著？」
這是 Bas Vodde 的同事問他的話，也是這篇文章要回答的問題。這是 Bas 在 Global LeSS Conference 2026 上的分享，我在東京聽了這場「健全なチームの動きを密かに計測する方法（Secret measurement of healthy team dynamics）」，背景是 Wärtsilä——一家 1834 年在芬蘭 Tohmajärvi 以鋸木廠和鐵工廠起家、現在導入 LeSS 的公司。Bas 是 LeSS 的共同創始人，也是 Odd-e 的創辦人，整場演講只圍繞一個數字：每個 Sprint 有幾個項目「開工了卻沒做完」。
我對這個題目有興趣，是因為它碰到了研發效能量測裡最難的一題：有沒有一個指標，便宜到團隊不會抗拒，又不會在被盯著看之後反過來傷害團隊？ Velocity 不行，say-do ratio 不行，程式碼行數更不行。講者的答案是 spill-over，而且他的理由不是「它量了什麼」，而是「盯著它看會讓人往哪裡走」。
下面我把演講的內容整理成一條完整的推論，並加上我自己的解讀。
整場演講的骨架：一張因果圖
Bas 用一張因果圖當作 Agenda，整場演講就是沿著這張圖的箭頭走一遍。每一節講完，對應的方框就被塗黃。
左邊三個是原因：個人主義式的團隊實踐、團隊對預防 spill-over 的知識、以及組織層級的 contract game。中間是兩個中介：團隊與組織的學習，以及這篇文章的主角——每團隊每 Sprint 的平均 spill-over。右邊兩個是結果：產品敏捷性與跨團隊協作。
讀這張圖的方式是：spill-over 不是目的，它是症狀讀數。 它被左邊三件事推高，又反過來侵蝕右邊兩件事。所以量它，等於同時量到左邊的病因和右邊的後果。這也是為什麼 Bas 說「量 spill-over 不只是量 spill-over」。
Spill-over 的精確定義：只算「開工了卻沒做完」
Spill-over 的定義比大家直覺想的窄：Sprint 結束時仍在進行中的項目數。選進 Sprint 卻完全沒碰的項目，不算。講者用三個例子把這條線畫清楚：
| 選入 Sprint | Sprint 內開工 | 完成 | Spill-over | |
|---|---|---|---|---|
| 例 1 | 10 | 5 | 4 | 1（不是 5！） |
| 例 2 | 1000 | 3 | 3 | 0 |
| 例 3 | 10 | 10 | 6 | 4 |
例 1 是整個定義的核心。十個項目選了五個開工、四個做完，直覺會說「差了六個」或「差了一個」，講者的答案是 1：五個開工的裡面有一個沒完成。那五個沒碰的呢？它們就只是還在 Product Backlog 裡，沒有任何半成品，下個 Sprint 要不要做由 PO 重新決定。
例 2 是刻意誇張的對照組。選了 1000 個項目，只開工 3 個、做完 3 個，spill-over 是 0。這在說：選了多少，跟這個指標完全無關。 團隊不需要在 Sprint Planning 時保守承諾來保護數字，PO 也不需要為了指標好看而少放項目。
例 3 則是典型的高 WIP 團隊：十個全部開工，六個做完，四個卡在半路。這四個半成品就是下個 Sprint 的包袱。
為什麼要這樣定義？因為 spill-over 想量的不是「團隊做了多少」，而是「團隊留下多少半成品」。半成品才是真正的成本：它佔住了人，佔住了下個 Sprint 的選擇權，而且還沒產生任何價值。
先劃清界線：這不是可預測性指標
講者在定義之後立刻放了一頁大字：NOT ABOUT PREDICTABILITY! 這個指標和 say-do ratio、計畫準確度毫無關係。
這頁放得很早，是有原因的。管理層一聽到「開工了卻沒做完」，第一個反應幾乎都是「所以這在量團隊有沒有守信用」。一旦被這樣理解，spill-over 就變成另一個 say-do ratio，團隊就會開始做所有 say-do ratio 會引發的事：少承諾、把項目估大、Sprint 最後一天趕工把沒做完的硬標成完成。
Say-do ratio 問的是「你說要做的有沒有做到」，分母是承諾。Spill-over 問的是「你開始做的有沒有做完」，分母是行動。前者獎勵保守，後者獎勵專注。這兩個問題看起來像，背後的誘因完全相反。
所以這頁其實是一支免疫針。它預先告訴所有人：這個數字不能拿來問責，不能拿來比較團隊守不守信用，也不能拿來評估估算準不準。它只回答一個問題——團隊在 Sprint 裡是怎麼工作的。
量測方法：一個終態、一次複製、一個平均
量測成本接近零，這是這個指標能「偷偷」用的前提。流程只有三步：
- Sprint 結束時，檢查每個項目：還在進行中嗎？
- 是的話，把它轉到一個終態叫「spill-over」。這個狀態是終點，項目在這裡結束。
- 複製一張新的項目：狀態設為進行中、清掉原本的估算、放進下個 Sprint。
然後指標就是：數一數這個 Sprint 裡有幾個項目落在 spill-over 終態。
「終態」這個設計值得多說一句。大部分團隊處理沒做完的項目，是把同一張卡拖到下個 Sprint。這樣做的問題是歷史消失了——半年後你完全看不出這張卡曾經卡過幾次。把 spill-over 設成終態、再複製一張新的，等於在資料裡留下一個永久的記號：這裡曾經有半成品。清掉估算則是提醒：剩下的工作量和原本估的無關，重新看。
在 LeSS 這種多團隊、單一 Product Backlog 的環境下，講者用的是產品層級的平均：整個產品的 spill-over 總數除以團隊數。他展示了一條橫跨 30 個 Sprint（S87 到 S116）的折線，數值多半在 0.4 到 1.2 之間擺盪，偶爾掉到 0 或衝到 1.6。
用產品平均而不是團隊排名，是刻意的。LeSS 的立場是整個產品群一起改善工作方式，不是找出「表現差的團隊」。一旦變成團隊排行榜，指標就死了。
為什麼這個指標難以作弊：被玩弄的方向就是你想要的方向
這是整場演講我認為最精彩、但講者沒有明講的一點。
Goodhart 定律說：一個指標一旦變成目標，就不再是好指標。Velocity 被當目標，團隊就把估算灌水；say-do ratio 被當目標，團隊就少承諾；bug 數被當目標，團隊就不回報 bug。幾乎所有研發指標都逃不過這條定律，因為「讓數字變好看」的捷徑和「真的把事做好」是兩條不同的路。
那 spill-over 呢？想讓 spill-over 變低，團隊能做什麼？
- 少開工一點，一次只做一兩個項目。
- 開工的項目全員一起把它做完，再開下一個。
- 看到放不下的項目就不要碰，或拆小。
- Sprint 最後一天不開新項目。
每一條「作弊」手段，都剛好是低 WIP、swarming、小批量——也就是你本來就希望團隊做的事。指標被玩弄的方向，和期望行為是同一個方向。 這是指標設計上非常罕見的對齊，也是它能「密かに」（偷偷地）使用的真正原因：你不需要防止團隊操弄它，因為操弄它就是在改善它。
唯一真正的作弊是把沒做完的硬標成完成。但那不是 spill-over 特有的問題，任何以「完成」為單位的指標都有，而 Definition of Done 和 Sprint Review 就是為此存在的。
Spill-over 大多可以預防：四道遞減的防線
講者的主張是「spill-over 大多數時候可以預防」，並給了四個戰術。這四個不是並列的選項，而是一條防線：每一道只處理前一道漏掉的情況，而且全部都在團隊自己手上，不需要管理層介入。
第一道：降低 WIP（結構性預防）
高 WIP 有兩種典型樣貌。一種是「每個人各做一張」：John 做 item 1、Pete 做 item 2、Claire 做 item 3、Alex 做 item 4，Sprint 進行到一半，四張全在進行中，WIP 是 4，每一張都有機會做不完。另一種是 WaterScrum：先把所有項目一起設計，再把所有項目一起實作，表面上大家在協作，實際上所有項目同時處於半成品狀態，直到最後一天才知道哪些真的完成。
對照的低 WIP 樣貌很單純：全隊先做完 item 1，再開 item 2。Sprint 進行到一半，WIP 是 1，最差的情況也只有一張做不完。
第二道：拆或換（Sprint 中期的調整）
做到 item 3 的時候，眼看 item 4 的大小塞不進剩下的時間。這時候的紀律是：不要開工 item 4。要嘛把它拆成能放進去的一小塊，要嘛跟 PO 換一個放得下的項目。重點是在 Sprint 中間就做決定，不要等到最後一天才發現。
第三道：最後一天不開工（末期紀律）
到了最後一天還有空，怎麼辦？講者的答案很明確：寫測試、學點東西、重構、把某個手動流程自動化。就是不要開新項目。一個最後一天才開的項目，幾乎注定變成 spill-over，而這一天的「閒置」其實是在償還技術債和投資能力，一點都不浪費。
第四道：Oh Fuck!（接受殘餘）
前三道都做了，最後一天還是發現 item 4 做不完——原本以為放得下，實際做起來比預期大。講者的這一頁標題就叫「Oh Fuck!」，底下寫著：別擔心，這會發生。重點是，如果你一次只做一張，最大的 spill-over 就是 1。這就是前三道防線真正的價值：它們不保證零，但保證上限。
根源一：團隊內部是「個人主義」還是「協作式」在工作
四道防線是症狀處理，講者接著往上追：為什麼團隊的 WIP 會高？答案是團隊內部的工作方式。他列了兩組對照。
要避免的個人主義式實踐：
- 每個人各有各的項目
- 按功能專業分工的順序流程（先設計、再開發、再測試）
- 每個人只做自己會的那項技能
- Feature hogging——一個人抱著一個大功能做好幾個 Sprint，講者戲稱這叫「什麼 Sprint？」
- 被依賴卡住
每一條都導向同一個結果：高 WIP、低協作、低知識分享。而且這三者互相強化——知識不分享，就只有一個人會做那件事，就只能一個人做，WIP 就下不來。
要嘗試的協作式實踐：
- 在 Sprint Planning 2 一起做設計，並拆出細粒度的任務
- 一天開多次 daily
- 同時跑多組 pair
- Mob programming
- Swarming——全隊撲向同一個項目
- 「犧牲一位成員」——指定一個人去擋住所有干擾和臨時插單，讓其他人專心把項目做完
這組的結果是低 WIP、高協作、高知識分享。
講者特別展開了第一條。在 Sprint Planning 2 一起設計，讓全隊對項目有相同的理解；拆成細粒度任務，讓一個項目可以被多人同時推進，而不是「這張卡是我的」；一天多次 daily，則是在任務變細之後增加同步點，不然大家各做各的小任務，一樣會散掉。他放了一張照片：四個人站在白板前討論架構，那就是 SP2 的樣子。
WIP 要看哪一層？ 講者強調他最在乎的是 Product Backlog Item 層級的 WIP，不是任務層級。一個 PBI 底下拆了六個任務、三個人同時做，任務 WIP 是 3，但 PBI WIP 是 1——這沒問題。反過來，三個人各做一個 PBI，任務 WIP 可能也是 3，但 PBI WIP 是 3——這才是問題。因為影響組織敏捷性的是「有幾個對客戶有意義的東西卡在半路」，不是「有幾個技術任務在進行」。
根源二：Contract Game，一條單向的承諾鏈
第二個根源在團隊之外。當團隊說「管它什麼 spill-over，這些 Sprint 根本是假的」，問題通常不在團隊，而在承諾是怎麼來的。
期限從哪來，又為什麼會變
講者先把期限分成四種來源，並且在旁邊列出每一種「為什麼會變」：
| 期限的來源 | 為什麼會變 |
|---|---|
| 硬性外部限制（法規、產品 EOL） | 用不同的 scope 滿足限制，或先做暫時的繞路方案 |
| 同步需求（行銷活動、流程變更） | 被同步的對象延誤了 |
| 對客戶的承諾（已賣出的合約） | 出現比舊承諾影響更大的新機會 |
| 激勵用（通常是隨便訂的） | 開發中發現意外 |
這張表的重點是右欄：四種期限全部都會變。連法規期限也會，只是變的方式是 scope 而不是日期。PO 拿到一個期限時，第一個該問的不是「做不做得到」，而是「這是哪一種」——因為每一種的談判方式不同。法規期限談 scope，同步期限談依賴，客戶承諾談機會成本，激勵期限直接戳破它沒有根據。
單向鏈 vs 雙向箭頭
Contract game 的樣子是一條單向鏈：客戶跟業務簽約 → 業務對 PO 做出承諾 → PO 對團隊說「給我趕上期限！」。講者在最後那個箭頭上畫了一個大紅叉。
對照的 collaborative development，每一段都變成雙向箭頭。業務和 PO 一起評估取捨，PO 據此更新優先序——排不同期限的先後、在高層級降低 WIP。PO 對團隊說明優先序和背後的理由，並且向團隊徵求 scope 建議，讓團隊幫忙想怎麼趕上期限。團隊不再是承諾鏈的末端，而是解法的來源。
排程的差別
講者用一張對照圖說明兩種模式下的排程。Contract game 這邊，四個團隊各自綁定四個客戶，每個 Sprint 都排滿，一路排到 Deadline 2——然後幾乎每個 Sprint 都被打了紅叉，因為排進去的東西根本不會如期發生。Collaborative development 這邊，PO 只排眼前一、兩個 Sprint，後面全部標著「Not scheduled」；Deadline 1 和 Deadline 2 用虛線箭頭連到 backlog，旁邊寫著「根據估算的投影」。
投影和排程是兩回事。排程是「這個 Sprint 這個團隊做這個」，投影是「照現在的速度和優先序，大概什麼時候會到那裡」。前者一改就全盤崩潰，後者每個 Sprint 自然更新。
Contract game 底下的 spill-over
當承諾是硬塞的，計畫會長這樣：六個項目平均攤在三個 Sprint，每個 Sprint 兩個。現實是三個 Sprint 過去只做完 item 1 和 item 2。這時候團隊看 spill-over 的態度就是「who cares」——因為 Sprint 邊界已經沒有意義，它只是一個被切成三段的大瀑布。所以講者把 contract game 放進因果圖：它直接推高 spill-over，而且讓團隊對這個數字麻木。
Spill-over 真正的代價：選擇權的喪失
一個項目晚一個 Sprint 交付，成本其實不高。Spill-over 真正貴的地方，是它預先決定了下個 Sprint 的優先序。講者用兩個場景說明。
場景一：產品敏捷性
Sprint 結束，item 2 沒做完。PO 看著 backlog 說：「我想 item 2 得繼續做，我會把它排在前面——因為它是 spill-over。」
注意這句話的邏輯。Item 2 被排在前面，不是因為它現在最有價值，而是因為它已經開始了。這就是沉沒成本在決定優先序。PO 本來在每個 Sprint 開始時擁有完整的選擇權，可以根據最新的市場和客戶資訊重排一切；一個 spill-over 就吃掉一部分選擇權。十個團隊各有一個 spill-over，PO 下個 Sprint 就有十個位置是被鎖死的。
場景二：跨團隊協作
LeSS 的 Sprint Planning 1 是所有團隊一起來、從同一份 Product Backlog 挑項目。這個設計的價值在於團隊可以互相調整：Team A 這次拿 item 5，Team C 幫忙接 item 2 的一部分。但如果 Team A 有一個 spill-over，其他團隊會說：「我猜 Team A 得繼續做 item 2，他們選它是因為那是 spill-over。」Team A 就被鎖在上個 Sprint 的決定裡，失去了和其他團隊協調的自由。
這就是因果圖右側兩個黃框的意思：每團隊每 Sprint 的平均 spill-over，直接減損產品敏捷性和跨團隊協作。產品層級的平均值在量的，其實是「整個產品群還剩多少自由度」。
這也解釋了為什麼 LeSS 這麼在乎 spill-over，而單團隊 Scrum 相對沒那麼在乎。單團隊的 spill-over 只鎖住一個團隊、一個 PO 的一小部分選擇；多團隊環境裡，每個 spill-over 都在縮小所有團隊共同的選擇空間。
計畫不可預測，成果可預測：給管理層的翻譯
講者有一頁專門處理管理層最常見的反駁：「不照計畫走，我們怎麼有可預測性？」他的回答分成兩句：
在變動的環境裡，靠「照計畫走」取得可預測性，會導致僵化，以及不切實際、傷產品也傷人的承諾。
靠「持續重排優先序」取得可預測性，得到的不是計畫的可預測，而是成果的可預測。
這段話值得翻譯一下。管理層要的其實不是「照計畫」，而是「能交代」。計畫驅動的可預測性是：三個月後的某一天，某個功能會上線。這在穩定環境裡成立，在變動環境裡則是每次都要靠加班和砍品質硬撐，撐不住就變成大家都知道是假的的甘特圖。
重排驅動的可預測性是另一種承諾：不管環境怎麼變，每個 Sprint 結束時，目前最有價值的東西會先出來。 日期和 scope 隨時在動，但「價值順序」這件事是穩定的。對業務來說，這等於可以隨時拿最新的投影去跟客戶談；對客戶來說，這等於他們最在乎的東西永遠在最前面。
這和前面「NOT ABOUT PREDICTABILITY」是同一個主張的兩面。Spill-over 不量計畫準確度，但 spill-over 低的組織，PO 手上的選擇權完整，重排才有意義，投影才可信。反過來，spill-over 高的組織，每個 Sprint 都有一半位置被半成品鎖死，重排只是形式，投影自然不準。
落地建議與限制
如果你想在自己的團隊試這個指標，幾件事要先想清楚。
不要讓它變成 KPI。 這是最重要的一條。「密かに」的前提是管理層不拿它問責、不排團隊名次。一旦公開排行，Goodhart 就回來了：團隊會開始在最後一天把沒做完的標成完成，指標立刻失真。最好的用法是團隊自己在 Retrospective 看它，或 Scrum Master 用它當對話的起點。
先跟團隊約定 Jira 的處理方式。 把 spill-over 設成終態再複製新卡，會讓 throughput、cycle time 等其他報表多出一堆「完成」的卡。事先說清楚哪些報表要排除 spill-over 狀態，不然會有人拿失真的數字來質疑你。
指標對項目大小敏感，但這是好事。 項目越大，越容易跨 Sprint，spill-over 越高。有人會說這不公平。但它正好把團隊推向拆更小的項目，而小項目本身就是敏捷性的來源。不要為了「公平」去做大小加權，加權會把這個推力抵銷掉。
Kanban 或沒有 Sprint 邊界的團隊，需要換一個等價量測。 Spill-over 依賴 Sprint 這個時間盒當作「結帳點」。沒有時間盒的團隊，可以看 aging WIP（每個進行中項目已經開工幾天）或 WIP 上限的違反次數，精神一樣：找出半成品。
「向團隊徵求 scope 建議」在台灣脈絡常卡住。 很多團隊習慣被告知 scope，不習慣主動提議砍功能，怕被當成推卸。這需要 PO 先示範——主動問「如果只能做一半，你們會留哪一半」，並且真的採納幾次，團隊才會相信這是認真的。
AI coding 時代的額外提醒。 當每個人手上都有一個能大幅提升個人產出的工具，最自然的滑坡就是回到「每個人各做各的」——反正一個人也做得完。這會讓 PBI 層級的 WIP 悄悄回升，而 spill-over 可能是最早能看出這件事的訊號。個人產出翻倍、但團隊 spill-over 也翻倍，代表你得到的是更多半成品，不是更多敏捷性。
結語：回答開場的問題
回到同事那句「你為什麼總是對 spill-over 這麼執著？」講者的回答是：
它是一個容易量測的指標，而且關注它會導向團隊內與跨團隊的協作，以及健康的 Product Ownership。
把整場演講壓縮成一條推論，是這樣的：
- Spill-over 只算「開工了卻沒做完」，所以它量的是半成品，不是產出，也不是承諾。
- 半成品來自高 WIP，高 WIP 來自個人主義式的團隊實踐，或來自組織層級的 contract game。
- 半成品真正的代價不是延遲，而是它預先鎖住了下個 Sprint 的選擇權——PO 的、也是所有團隊共同的。
- 要壓低它，團隊能做的事（降 WIP、swarming、拆小、最後一天不開工）剛好就是你希望團隊做的事，所以這個指標幾乎不會反噬。
- 因此它可以「偷偷」用：不需要管理層盯，不需要排名，團隊自己看就會往對的方向走。
我自己最大的收穫，是重新理解了「一個好指標長什麼樣」。它不必精確，不必涵蓋全貌，甚至不必被所有人理解。它只需要兩個性質：量測成本夠低，以及被操弄的方向和期望行為一致。Spill-over 兩個都有，這在研發指標裡非常稀有。
參考：講者引用的 less.works 部落格文章〈In-team and cross-team collaboration practices〉，對團隊內與跨團隊的協作實踐有更完整的整理。
發佈留言