星期一的 Sprint Planning，工程主管把看板投到螢幕上。

Ready for Development: 31
In Development: 7
Waiting for Review: 4
QA: 3

三個月前，Ready for Development 通常只有十幾張。現在幾乎翻倍。

主管不太擔心，因為同一份報告還有另一個數字。

Average Coding Time

Before AI Coding: 2.1 days
Current: 0.8 day

AI Coding 確實讓工程師更快補測試、改 API Client、整理重複程式。過去要一兩天的小需求，現在半天就能送出 Pull Request。

「既然 Coding 快了一倍，這季多接一些。」主管說。

沒有人反對。那個效率提升是真的。

於是原本排到下個月的十幾個需求，被提前拉進 Sprint。

星期三，一位工程師處理：

Add Region Filter to Revenue Dashboard

AI 幫他找到 Query、補上 Filter Logic，也產生了測試案例。下午一點四十分，PR 已送出。

Coding Time: 3h 40m

他把卡拖到 Waiting for Review，接著開始下一張。

星期五，Reviewer 留下一個問題：

APAC Region 是否包含 India？

需求文件沒寫。工程師問 PM，PM 再去找 Finance Team。星期一才拿到答案。

修改後重新送 Review，星期二通過。接著進 QA，測試人員發現 Export Function 也要套用同一個 Region Filter；需求文件仍然沒提。

卡片又退回 Development。

真正修改程式只花四十多分鐘。這次再送 Review 時，前面已經排了十一張 PR。

那張三個多小時寫完的需求，第九個工作天才上線。

變快的不是整份工作

兩個月後，Kanban Board 很乾淨，也很塞。

In Development 變短了。工程師拿到工作後，常常當天就能送 PR。

但每一張卡更快離開 Development，就更快進入下一個 Queue。

Review Team 收到更多 PR；QA 同時要驗證更多 Change；PM 被追問更多需求細節。Security Review、Release Window 和 Approval 的容量卻沒有一起增加。

Ready
████████████

Development
███

Waiting for Review
████████████████

QA
██████████

主管問：「大家都變快了，Delivery 為什麼沒有快多少？」

問題就在「大家都變快了」。

AI 壓縮的是 Coding。從需求被接受到使用者拿到結果，還有需求確認、Review、修正、QA、核准與上線等待。

Coding Queue 變短，不等於 End-to-End Cycle Time 也會等比例變短。

更麻煩的是，組織看到工程師空出時間，通常立刻把它當成新的承諾量。

小需求以前不值得做，現在可以做；一張大需求可以拆成更多小 Change；Stakeholder 也會更快把需求送進來。

於是原本被省下來的 Capacity，很快被新的 Demand 吃掉，壓力被送往下一個還沒擴容的瓶頸。

這不是 AI 失效。它只是更快讓團隊撞到原本藏在後段的限制。

團隊後來只改看一個時間

下一季，主管沒有再用 Average Coding Time 決定可以多接多少需求。

那個指標仍然保留；工程師也持續改善它。但 Planning 時，團隊開始看 End-to-End Cycle Time：工作被正式接受，到使用者真正拿到結果，中間到底花了多久。

REQ-1842

Accepted: Aug 3 10:14
PR Created: Aug 4 13:02
Review Complete: Aug 8 16:41
QA Complete: Aug 11 11:18
Released: Aug 12 15:00

Coding 不到四小時，完整 Cycle Time 超過九天。

這條時間線沒有否定 AI 的效果。它只是指出，下一個最值得處理的地方已經不是 Coding。

團隊因此不再直接增加 Sprint Intake。先限制同時進行的工作數，也替 Review 留出固定 Capacity；前一批真正離開 QA 和 Release，下一批才繼續進來。

下一次 Planning，主管看著右邊：

Waiting for Review: 9
QA: 7
Waiting for Release: 4

最後有六張需求留在下一個 Sprint。

不是工程師寫不完。恰好相反。

工程師已經寫得夠快了。再塞六張進去，只會更早把它們搬到另一條 Queue 排隊。

看板上的 Development 仍然只有短短一排。

最右邊的 Waiting for Review，卻排了兩行。

這次，團隊沒有把那兩行解讀成「還可以再做更多」。