Scrum 團隊的噩夢：面對「半路殺出的急件」，如何優雅應對？

本文作者：柯仁傑 (三叔公)

在實施 Scrum 的理想狀態下，Sprint Backlog 一旦在開發計畫會議（Sprint Planning）中確認，就像是一份神聖的契約：在 Iteration 中途不增加功能，也不隨意變更週期長短。

然而現實往往是殘酷的。業務急著說：「沒這功能客戶不簽約！」、產品經理焦慮地喊：「這不先做會流失市場！」甚至還有突發的嚴重線上 Bug（Hotfix）需要救援。面對這些「忽然插單」的要求，Scrum 團隊該如何處理才最合理？以下提供六個具體的應對策略與深層思考。

策略一：嚴格把關，別讓「黃牛需求」透支團隊

許多急件其實是源於溝通上的「通膨」。當 Sales 或 PM 聲稱「沒這功能就賣不出去」時，產品負責人（PO）必須發揮守門人的價值，仔細評估其商業價值與真實急迫性。

• 重點： 如果頻繁讓無效需求插單，工程師會因計畫反覆而產生職業倦怠，導致開發速率下降。PO 應慎重告知需求方，過多的「黃牛插單」最終會造成雙輸。

策略二：時間換空間，延後至下個 Iteration

很多看似「現在就要」的需求，其實只需要 PO 展現溝通技巧。

• 做法： PO 先承接需求並進入分析階段，進行規格確認與評估。當這套流程跑完時，往往已經接近當前 Sprint 的尾聲。
• 優點： 讓需求順理成章地排入下一個 Iteration，既能維持 Scrum 的作息，也給了團隊足夠的準備時間。

策略三：等價交換，拿未開工的 Story 來換

如果急件真的「今天就要動工」，那麼為了維持團隊的工作負荷量（Capacity），必須採取對等交換。

• 做法： 檢視本週期內尚未開工的 Story，將其退回 Backlog，並換入同等規模（或較小）的緊急事件。
• 優點： 這能強迫需求方理解「資源有限」的現實。雖然仍需花時間重新評估與拆解 Task，但至少能止血，避免工作量無限膨脹。

策略四：預留 10% 的緩衝彈性（Buffer）

如果你的環境中，「意料外的雜事」是常態，那麼在計畫階段就不該「滿載」。

• 做法： 每次 Sprint 只投入 90% 的火力，保留 10% 的能量處理不時之需。
• 缺點： 這是一把雙面刃。如果急件過於頻繁或過於複雜，這 10% 可能杯水車薪。

策略五：轉型 Kanban 模式，追求動態流動

如果你的組織環境本質上就是充滿隨機性的（例如維運導向、頻繁變動的代理商環境），那麼或許 Scrum 的 Iteration 限制反而是一種束縛。

• 做法： 考慮採用看板（Kanban）。不設定固定的開發週期，只要手頭任務完工，下一個就處理優先順序最高的急件。

策略六：分而治之，設立兩支團隊

這是一種更徹底的結構化做法。

• 做法： 安排一個團隊專注於 Sprint 的新功能開發，另一組人馬（如維運組或 On-call 組）專門處理突發急件。
• 優點： 這能讓開發團隊完全進入「心流狀態」而不被打斷，但前提是組織的人力資源必須足夠。

結語：救急不救窮，解決根源才是王道

無論採取上述哪種策略，都只是「治標」。身為敏捷實踐者，在救火之餘，更值得深入思考以下兩個核心問題：

1. 需求的源頭出了什麼問題？ 為什麼 PM 或 Sales 的規劃老是跟不上市場？是市場變化真的太快，還是前期的市場調查與需求溝通不夠紮實？
2. 技術的穩定度出了什麼問題？ 為什麼老是有重大 Bug 需要立即修復？是否應該回頭加強單元測試、自動化監控或改善程式架構？

救急只是應變，解決源頭問題才是根本。 透過魚骨圖分析找出「急件產生的原因」，才能真正讓團隊從消防員轉型為創造價值的開發者。