團隊可能不缺敏捷做法，缺的是一套能讓 Scrum 決策、回饋與自管理循環運作的管理系統。

Sprint Planning、Daily Scrum、Sprint Review、Retrospective，一場都沒有少。

Jira 每天有人更新，燃盡圖也畫得出來，Velocity 看起來還算穩定。管理報表上，每個人手上都有工作，團隊忙得不可開交。

但到了季度檢討，主管看到的問題還是一樣：發布日期一再延後，重要需求持續插隊，跨團隊依賴遲遲沒有解決；Sprint Review 展示了不少新功能，客戶行為與業務數字卻沒有明顯改變。Product Owner 遇到取捨仍然向上請示，團隊遇到阻礙也在等主管作決定。

於是管理階層開始懷疑：「Scrum 都做了，為什麼團隊還是交不出成果？」

問題往往出在大家把「做了 Scrum」理解成「完成 Scrum 的活動」。會議有開、角色有設、工具有更新，不代表 Scrum 已經在組織裡發揮作用。

我在這裡說的成果，不能用完成多少張 PBI、Velocity 增加多少，或團隊在 Sprint 內寫了多少程式來衡量。成果是可使用、可驗證，而且能推動業務或使用者目標的產品增量。活動和功能是產出；它們讓使用者行為、客戶體驗或業務結果發生改變，才算成果。

Scrum 不會自動創造成果。它提供一套有節奏的透明、檢視與調整機制，讓團隊透過小批次交付取得真實證據，再用證據調整決策。如果團隊不能作決定、看不到結果，或看到結果後也不能調整，Scrum 活動做得再完整也只剩儀式。

Scrum 真正要建立的，是有邊界的自管理能力

複雜產品很難在一開始就找到完整答案。主管可能清楚戰略方向，Product Owner 可能熟悉市場與使用者，Developers 最了解技術限制與交付方式；但沒有任何一個角色能單獨預知哪個方案一定有效。

因此，Scrum 不是把一份事先確定的計畫拆成若干個 Sprint 執行，而是讓 Scrum Team 在明確目標與邊界內，反覆經歷一個循環：

戰略意圖與邊界 → 作出產品與交付決策 → 交付小批次增量 → 取得產品及流程證據 → 檢視與調整 → 作出下一次決策

Product Goal 與 Sprint Goal 提供方向；Product Backlog 與 Sprint Backlog 讓選擇及進展透明；Increment 讓討論回到可觀察的結果；Scrum Events 則提供固定節奏，讓團隊定期檢視產品、計畫與工作方式。

Scrum 也透過這套安排培養自管理能力。依照 Jeff Sutherland 與 Ken Schwaber 共同撰寫的 2020 Scrum Guide，自管理是指 Scrum Team 內部決定誰做什麼、何時做及如何做；組織則需要建構並賦予團隊管理自身工作的空間。整個 Scrum Team 對產品相關工作負責，Product Owner 對 Product Backlog 的有效管理負責，Developers 則自行決定如何把選定的 PBI 轉化為可用的 Increment。The Scrum Guide

自管理有清楚的前提：團隊不能想做什麼就做什麼，主管也不能因此退出領導。主管仍要提供戰略方向、資源與組織邊界；Scrum Team 在這些條件內管理工作、調整協作方式，並對交付結果負責。目標、邊界與責任不會削弱自主管理，它們讓團隊知道自己可以決定什麼，又必須承擔什麼。Scrum Inc：The Scrum Team、Jeff Sutherland：The Manager’s Role in Scrum

這套節奏也能幫助主管逐步放權。主管不必從第一天就完全放手，可以先給出有限的決策範圍，觀察 Product Owner 如何說明取捨、團隊的預測與結果是否愈來愈一致，以及新證據出現時，團隊會不會調整原本的判斷。

信任因此有了可觀察的依據。它會隨著一次次可見的決策與結果累積：

小範圍授權 → 可見的決策與結果 → 累積信任 → 擴大授權 → 承擔更完整的成果責任

我把這種方式稱為「迭代式授權」。高階主管先給中階主管與 Product Owner 清楚的戰略意圖、成果標準及風險邊界；當他們在邊界內持續展現可靠判斷，再逐步擴大資源額度、決策範圍，或降低請示頻率。

Sprint Review 不能在這個過程中變成老闆逐項核准功能的驗收關卡。它應該讓大家一起檢視產品證據、外部變化與下一步方向。如果每次 Review 都在等上級批准，授權循環反而會在這裡中斷。

接下來這七個症狀，是自管理循環失效時，主管最常看到的表面現象。

症狀一：團隊知道公司目標，卻不知道該放棄什麼

很多團隊不是沒聽過公司戰略。他們參加過年度大會，看過 OKR，也知道今年的關鍵字。但當你問：「這個 Sprint 希望改變什麼結果？為什麼現在做這些工作？」答案往往是「主管要求的」「需求單已經排進來」或「這幾張票優先級最高」。

目標有沒有用，要看它能不能幫助團隊取捨。讓所有人背得出來還不夠；如果它無法回答什麼該做、什麼暫時不做，就只是一句方向正確、決策無用的口號。

團隊可以完成大量工作，卻不知道這些工作是否共同推動某個成果。Sprint Goal 也很容易變成「完成七張票」「修復十個問題」的工作清單，沒有一個值得整個團隊共同追求的結果。Sprint 目標提供目的性

共同方向不清楚，團隊就很難自行作局部取捨，主管只好不斷補充指令。久了以後，團隊會把等待下一個任務當成最安全的做法，不再練習判斷。

主管先問：任意詢問三位團隊成員：「這個 Sprint 希望改變什麼結果？為什麼這些工作比其他工作重要？」三個人的答案是否一致？

先做一步：選擇一個產品成果，明確寫出希望改變的對象、行為或指標，再把它連到 Product Goal、Sprint Goal、PBI 與驗證訊號。先建立目標與決策的關係，不用急著再開一次目標宣導會。

症狀二：Product Backlog 只活到下一個 Sprint

有些 Product Backlog 只有下一個 Sprint 的工作。Sprint Planning 前，Product Owner 才開始四處收集需求；Planning 結束後，團隊又看不見接下來要驗證什麼、可能何時發布，以及有哪些依賴或風險需要提前處理。

Product Backlog 並不是越長越好。有些產品確實不需要預先細化很多個 Sprint；把未來半年所有 PBI 都拆解、估算、鎖定日期，反而會浪費大量時間。巨大而無法維護的 Product Backlog，本身也是常見反模式。產品待辦列表梳理的藝術、巨大的產品待辦列表

組織若沒有成果導向的產品路線圖與發布計畫，Product Backlog 就只剩下一個 Sprint 的任務。團隊無法提早處理跨團隊協作、法規、採購、資料或部署限制，也無法安排最重要的驗證節點。

比較實用的是逐步細化的滾動規劃：遠期保留要解決的問題、產品成果與策略主題；中期呈現可能的發布範圍、驗證節點、依賴及風險；近期才把高優先工作梳理到足以開始。每次得到新證據，再調整後續計畫。

這種 Roadmap 要同時讓主管看見方向、團隊看見選項，並保留因應新證據調整的空間。它不是一張承諾半年後必定交付哪些功能的清單。

主管先問：除了下一個 Sprint，團隊是否知道接下來想驗證什麼、可能以什麼順序發布，以及哪些條件可能阻礙成果？

先做一步：建立一張成果導向的滾動 Roadmap，標示驗證節點與主要風險。遠期保持粗略，近期逐步清晰；不要把它做成固定功能與固定日期的專案承諾表。

症狀三：每個優先級決策最後都要向上請示

當 Product Backlog 裡每件事都是最高優先，RICE、WSJF 或其他排序公式通常也解決不了問題。工具可以協助比較，不能替組織作取捨。

更常見的情況是，主管沒有給出足夠清楚的戰略方向與決策標準；Product Owner 也還沒透過透明的決策依據、風險說明與成果回饋，建立足以支撐決策權的信任。於是不同部門可以直接插單，Product Owner 每次遇到爭議都必須向上請示，原有排序也跟著權力關係反覆改變。

接著就會形成一個惡性循環：戰略邊界模糊，Product Owner 的判斷難以解釋；主管因此持續介入；Product Owner 沒有實際的決策空間，也就無法累積經驗與可信成果；更多決策只好繼續向上集中。

決策權不會靠主管單方面「賜予」，也不會因為 Product Owner 強勢表態「爭取」就自然出現。雙方需要共同建立一份決策契約：主管說清楚戰略意圖、取捨原則、資源與風險邊界；Product Owner 則說清楚為什麼選這個、不選另一個，依據哪些證據，何時重新評估，以及什麼情況需要升級。

沒有實際決策，就沒有機會練習判斷，也很難對結果負責。團隊表面上被要求當責，手上其實只有執行責任。

主管先問：Product Owner 是否能清楚說明目前的取捨、假設與重新評估條件？他又是否知道哪些決策可以自行作出、哪些情況必須升級？

先做一步：先選一個有限範圍建立決策契約，再透過數個 Sprint 檢視決策品質。當 Product Owner 能持續根據證據修正判斷，就逐步擴大授權，不要一遇到問題便收回全部決策權。

症狀四：還沒想清楚的 PBI 已經進了 Sprint

有些團隊到了開發中段，才發現 Product Owner、Developers 與干係人對需求的理解完全不同。驗收標準不清楚，完成與否靠臨場判斷；PBI 太大，Sprint 過了一半才發現做不完；依賴、風險及技術未知，也是在作出承諾後才浮現。

這時最常見的補救，是要求每張 PBI 補上 Story Points 或更多欄位。但估算數字不會自動帶來共同理解。Story Points、粗略尺寸或歷史週期時間都可以作為預測工具，團隊仍然要理解預期結果、驗收方式、規模、依賴與主要未知。

工作若在缺乏共同理解時就開始，返工、延遲與無法完成的增量幾乎無法避免。團隊的預測也會持續失真，因為他們承諾的是別人交下來的假設，不是經過共同理解的工作。

這樣的團隊也很難自主管理。沒有參與澄清、切分與揭露風險，就不可能作出負責任的預測，只能替模糊需求承擔交付壓力。

主管先問：團隊能否說明這項工作要解決什麼問題、如何確認完成，以及目前最大的未知是什麼？

先做一步：讓 Product Owner 與 Developers 在 PBI 進入 Sprint 前，一起確認預期結果、驗收方式、規模、依賴與不確定性。估算的用途是降低決策風險，不能拿來製造看似精確的承諾。Definition of Ready 可以作為團隊的對話提示，幫助大家判斷是否已有足夠的共同理解；但如果它變成由上游填完文件、通過關卡後才交給下游執行的固定清單，甚至要求所有細節在 Sprint 前完全確定，Refinement 就會退化成另一種階段式瀑布流程。

症狀五：每個人都很忙，工作卻流不動

知識型組織處理資訊有多快，工作就能多快往成果移動。使用者問題要被理解，戰略要轉成優先順序，需求要經過產品與技術判斷，完成的增量還要發布、驗證，再把新證據帶回下一次決策。資訊只要停在其中一個環節，工作即使有人處理，也沒有真的向成果前進。

「每個人都很忙」有時反而表示系統裡塞了太多尚未完成的資訊與工作。需求等待澄清、決策等待主管、程式等待審查、功能等待測試、發布等待其他團隊。每個部門的局部效率看起來都很好，整體資訊卻在佇列、交接與阻塞中緩慢移動。

這時把一件新工作標成最高優先，也不會讓它自然變快。優先級不能創造容量。它不是排在大量 WIP 後面等待，就是中斷原有工作，帶來更多任務切換與半成品。主管以為自己在加速，其實只是重新分配等待時間，最後連原本快完成的工作也一起變慢。

成果要到達使用者並取得回饋，這段路才算走完。高 WIP、過大批次、反覆交接與跨團隊依賴，會持續拉長從想法到回饋的時間；當每個人都被排到百分之百滿載，組織也就沒有空間回應真正的緊急事件。沒有 WIP 限制的反模式

主管不用一次追蹤一大堆流動指標，先看兩個就好：第一，從需求或決策進入系統，到交付並取得使用者回饋需要多久；第二，系統目前同時進行多少工作，也就是 WIP。前者反映資訊與價值流動的實際速度，後者可以看出系統是否已經壅塞。發現異常後，再用其他數據追查等待發生在哪裡。

這同樣會影響自管理。如果組織只獎勵每個人保持忙碌，團隊自然會把注意力放在「我的任務」，而不是「我們怎麼讓最重要的工作走到完成」。最後，每個人只是在管理自己的待辦事項，沒有人共同管理端到端價值流。

主管先問：如果今天進來一件最高優先的工作，團隊要停止什麼，多久能把它交付並取得回饋？資訊最可能在哪個環節等待？

先做一步：把需求進入系統到取得使用者回饋之間的資訊與工作流畫出來，限制 WIP，並為真正的緊急事件訂出處理規則、保留可用容量。每增加一件高優先工作，就要明確決定哪一件工作暫停；先一起完成老化或阻塞的工作，再啟動新的工作。

症狀六：Sprint Review 展示很多，Product Backlog 卻從不改變

不少 Sprint Review 看起來很熱鬧：團隊逐項展示功能，干係人給幾個介面意見，最後宣布完成比例。但真正使用者不在場，發布後也沒有追蹤行為或結果。無論得到什麼證據，下一個 Sprint 仍然照原定功能清單進行。

這場 Review 做的是進度展示，不是產品學習。

做出功能不代表結果會改變。若開發前沒有說清楚要驗證的假設，也沒有定義成功或失敗的訊號，團隊只能加快製造功能，卻無法提高找到正確方向的機率。沒有成效的功能甚至會繼續獲得投資，只因為它已經出現在 Roadmap 上。

MVP 是驗證手段之一，不是功能較少、品質較差的第一版。原型、訪談、冒煙測試、人工服務、小流量發布，都可能比完整開發更快取得證據。重點是用最小成本，拿到足以改變下一步決策的資訊。試驗的力量

團隊若看不到自己的決策造成什麼結果，就無法改善產品判斷；主管也沒有依據判斷是否應該擴大授權。自管理循環就在這裡失去了「回饋」。

主管先問：最近三次發布分別驗證了什麼假設？有哪些證據真正改變了 Product Backlog？

先做一步：挑選下一項高風險工作，寫出假設、成功或失敗訊號，以及取得證據的最小做法。讓 Sprint Review 討論「我們學到了什麼，下一步因此如何改變」，不要只確認功能是否完成。Review 是共同調整方向的場合，不是主管逐項核准的關卡。

症狀七：回顧會有很多行動，下一次又談同樣的問題

每次 Retrospective 都能找到問題，不代表團隊一直在改善。

問題出在每次都有一長串行動項，卻沒有負責人、完成期限或成功判準；改善工作沒有放進任何可見的工作系統，也沒有預留容量。超出團隊權限的障礙無處升級。到了下一次回顧會，大家沒有先檢查上次行動，又重新列出「加強溝通」「改善協作」等相似項目。

久了以後，回顧會會從改善機制變成情緒出口。團隊知道問題，卻沒有能力改變；缺陷、等待與協作摩擦持續侵蝕交付能力，成員也逐漸覺得提出問題沒有意義。

自管理除了安排眼前的工作，也包括改善自己的工作系統。團隊若沒有容量、權限或回饋去改變工作方式，就不可能對成果承擔完整責任。

主管先問：上一次回顧會選擇了什麼改善實驗？現在有哪些證據顯示它有效、無效或需要調整？

先做一步：每個 Sprint 優先選擇一項高影響改善，指定負責人、預留執行容量並定義觀察訊號。下一次回顧先檢查它，再決定保留、調整或停止。若問題超出團隊邊界，主管需要建立明確的升級與處理管道。

別同時修七個症狀，先修復一個循環

七個症狀看起來各不相同，但都表示 Scrum 的自管理循環少了一個必要條件。

方向不清 → 無法滾動規劃 → 決策持續向上集中 → 工作在缺乏共識時開始 → 價值流動受阻 → 沒有產品學習 → 也沒有系統改善

如果組織要求團隊自主管理，卻保留所有重要決策，團隊很難真的對成果負責。同樣地，要求 Product Owner 先證明自己值得信任，卻不給他作決定、看到結果並修正判斷的空間，信任也無從累積。

看完七個症狀，也不要同時啟動七項改革。那只會再次出現「改善項太多、沒有完成」的問題。

先用七個問題檢查你的管理系統：

1. 團隊能否一致說出目前要改變的業務或使用者結果？
2. 除了下一個 Sprint，是否看得到成果導向的產品路線與驗證節點？
3. Product Owner 是否知道哪些決策可以自行作出、哪些情況必須升級？
4. 團隊是否在開始工作前形成足夠的共同理解？
5. 是否有人關注從想法到使用者回饋的端到端時間？
6. 最近的產品證據是否真正改變過 Product Backlog？
7. 上一次回顧會的改善實驗是否被執行及檢查？

找出目前最限制成果的一個症狀，定義希望改變的可觀察訊號，選擇一項最小的管理系統實驗，執行兩至三個 Sprint。之後再根據結果決定保留、調整或停止。當中階主管、Product Owner 與團隊的決策品質逐漸獲得信任，高階主管就能有節奏地擴大授權，不必在嚴密控制與完全放手之間反覆擺盪。

先別為 Scrum 增加更多規定。修好一個中斷的決策與回饋循環，團隊才有機會重新對成果負責。

延伸閱讀

Scrum、自管理與主管角色

• The Scrum Guide（官方）
• Scrum Guide Revisions: Self-Managing over Self-Organizing
• The Scrum Team — Scrum Inc.
• Why Does Scrum Require Self-Managing Teams? — Scrum.org
• The Manager’s Role in Scrum — Jeff Sutherland

產品目標、Product Backlog 與滾動規劃

• Sprint Goals Provide Purpose: A Guide — Mark Levison
• The Art of Product Backlog Refinement — Stephanie Ockerman
• Scrum Anti-Patterns: Large Product Backlog — Mark Levison

成果驗證、資訊流動與 WIP

• Business Outcomes Based Metrics: How to Effectively Measure Your Agile Transformation Journey — Andy Cleff
• The Power of Experimentation — Blake McMillan
• Antipattern of the Month: Unlimited WIP — Ian Mitchell
• Why Less Communication Is Better — Jeff Sutherland

作者簡介

范育銘曾多次參與組織敏捷轉型，關注數位化轉型、團隊與組織級敏捷實踐。他曾以敏捷教練角色服務不同規模的公司，並與朋友共同創辦 Weagile 社群。目前主要透過引導、培訓與工作坊，協助團隊建立共識、制定目標並推進變革。(https://weagile.io/)