← 隨筆

AI 與 Scrum 事件：開發團隊會議中真正改變的是什麼

系列總結：AI 如何改變 Scrum 事件、在何處幫助團隊、放大了哪些風險，以及為什麼責任仍留在人身上。

13 分鐘閱讀
Telegram原文
AI 與 Scrum 事件：開發團隊會議中真正改變的是什麼

這是關於 AI 如何改變跨職能開發團隊經典會議的系列總結文章。在前幾部分中，我分別剖析了 Backlog Refinement、 Sprint Planning、 Daily Scrum、 Sprint Review 和 Sprint Retrospective。如果把這些放在一起，整體結論相當清醒：AI 讓 Scrum 事件的準備變得更便宜、更豐富，但不會從團隊手中拿走對檢視、調適、對話和真正改變的責任。

當我開始這個系列時，很容易陷入兩種極端情境之一。第一種：AI 很快會取代幾乎所有團隊會議，因為模型已經能夠摘要、撰寫任務、生成計畫、彙整狀態、準備演示並提出行動項目。第二種：Scrum 事件本質上如此人性化，以至於 AI 在那裡幾乎無用武之地。

經過五篇獨立剖析後，我認為這兩種情境都過於扁平。

AI 確實正在改變團隊會議。但不是廣告承諾中通常說的那樣。它改變的不是 Scrum 事件的核心，而是它們周圍的層：準備、搜尋、摘要、初步結構化、信號偵測、決策記錄和後續跟進。而當這一層變得越便宜，那些無法在不失去意義的情況下自動化的東西就越發明顯：團隊判斷、責任、關於價值的爭論、現實檢驗、心理安全感，以及改變計畫、待辦清單或工作方式的能力。

「AI 讓準備變得更便宜，但也讓人類責任變得更明顯。」

這就是對本系列問題的主要回答。AI 不會廢除跨職能開發團隊的經典會議。它改變的是這些會議的注意力經濟。例行的事實收集變得更便宜。製作整齊的草稿變得更便宜。狀態溝通變得更便宜。但 Scrum 事件的真正價值仍然出現在團隊審視事實、爭論意義、達成妥協並改變後續行動的地方。

首先，回到會議的目的會有所幫助

在 Scrum Guide 2020 中，Scrum 事件被描述為不是一套儀式，而是內建的透明度、檢視和調適機會。Sprint Planning 啟動衝刺，幫助團隊就價值、工作範圍和執行方式達成一致。Daily Scrum 是供開發者檢查朝 Sprint Goal 的進展並調適 Sprint Backlog 之用。Sprint Review 用於檢視成果並進一步調適 Product Backlog。Sprint Retrospective 用於提升團隊工作的品質和效能。

Backlog Refinement 則另當別論：它不是 Scrum Guide 2020 中的正式 Scrum 事件，而是持續精煉 Product Backlog 的活動。但在跨職能團隊的現實中，refinement 往往作為重要的定期會議或一系列工作坊運作。因此在本系列中，我把它與經典事件並列剖析：正是在那裡，團隊首次面對大量手動的智力準備工作，而 AI 最早開始加速的也正是這一塊。

這個框架很重要，因為它能防止錯誤的提問。糟糕的問題是：「AI 能取代哪個會議？」更精確的問題是：「AI 能接手哪部分手動準備，讓會議本身成為更誠實的檢視與調適？」

作為額外參考，在本系列最後幾篇文章中我使用了 Scrum Guide Expanded v2026.1。它應該被理解為基於 Scrum Guide 2020 的輔助來源，而不是 Scrum Guide 的新正典版本。就 AI 主題而言，其中有用的表述是將模型視為受監督的決策夥伴：AI 可以強化透明度、檢視和調適，但不能取代人類責任，也不應廢除經驗過程控制。對總結文章來說，這幾乎是完美的界線。

在全部五部分中反覆出現的內容

在關於 Backlog Refinement 的文章中，主要結論是：AI 加速的不是團隊的共識本身，而是為共識準備材料。它幫助收集背景、使用者故事的草稿、驗收標準、風險、開放問題和初步解決方案選項。但它也製造了虛假清晰度的風險：任務看起來很清楚，只因為它被很好地格式化了。

在關於 Sprint Planning 的文章中，類似的模式在另一個層面顯現。AI 幫助更快地彙整 Sprint Goal 選項、工作範圍、依賴關係、分解和風險。但出現了虛假的現實感：計畫看起來連貫、完整且可執行，儘管團隊尚未根據產能、Definition of Done、可測試性和真實限制對其進行檢驗。

在 Daily Scrum AI 已不再準備未來的工作，而是收集關於衝刺進展的訊號。它可以標示出阻礙、審查瓶頸、不穩定的測試、Jira 狀態與現實之間的落差、依賴關係，以及非同步做出的決策。但如果焦點從 Sprint Goal 偏離到「誰忙了些什麼」，Daily Scrum 就會變成 AI 生成的狀態報告。

在 Sprint Review 中，AI 可作為衝刺成果、指標、release notes、回饋與未解產品問題的準備層。但同樣在這裡，demo theater 的風險特別明顯：模型把回顧做得漂亮，團隊展示一段打磨過的故事，利害關係人點頭，而 Product Backlog 卻沒有改變。

在 Sprint Retrospective 中，AI 可以為對話帶來硬證據：反覆出現的阻礙、等待審查、未完成的 action items、與 Definition of Done 的落差、反覆出現的模式。但改善不會從建議清單中誕生。只有當團隊承認問題、選擇一項改變、指定 owner 並把它帶到下一個衝刺，改善才會出現。

如果把這些結論並排攤開，會浮現一個共同的圖像：AI 幾乎在每個地方都讓會議的輸入變得更豐富。而幾乎在每個地方，它也製造了把豐富輸入誤當成已做決策的誘惑。

Scrum events 的變革地圖

會議／實務 AI 降低了什麼的成本 仍留在人身上的部分 主要風險
Backlog Refinement 蒐集脈絡、草擬需求描述、驗收準則、邊界情況、未解問題。 驗證意義、領域規則、技術限制，以及是否準備好討論該任務。 虛假的清晰：任務因為寫得好而看起來已經就緒。
Sprint Planning Sprint Goal 的選項、scope、依賴關係、風險、拆解、測試情境。 團隊對目標、範圍、現實性、Definition of Done 與衝刺承諾的決定。 虛假的現實感：計畫因為組得順暢而看起來可行。
Daily Scrum 關於衝刺進展、阻礙、PR、測試、決策與依賴關係的預先訊號。 Shared awareness、Sprint Backlog 的調適，以及接下來的工作要改變什麼的決定。 狀態機器人：會議變成關於人的報告，而不是關於 Sprint Goal 的對話。
Sprint Review Release notes、成果的全貌、產品指標、回饋與未解問題。 對增量進行誠實的檢視、與利害關係人的對話，以及 Product Backlog 的調適。 展示劇場：展示得很漂亮，但沒有做出產品決策。
Sprint Retrospective 關於流程的事實、反覆出現的模式、舊的 action items、對話所需的證據。 心理安全感、承認問題、選擇改善，以及 follow-through。 以 AI 建議清單取代團隊行為的改變。

這張表並不是說 AI「改善了 Scrum」。那會是太強的主張。關於 AI 輔助 Scrum events 的直接獨立證據基礎目前仍然很少，而在本系列個別的 research briefs 中，我特別指出了這個缺口。更審慎的表述不同：AI 可以強化成熟的檢視與調適實務，但如果團隊裡早已存在舊的反模式，它也同樣容易將其強化。

這與 DORA State of AI-assisted Software Development 2025: 的謹慎框架相當吻合：AI 不應被視為更好 delivery 的獨立保證，而是既有組織系統的放大器。如果團隊懂得討論價值、風險、品質與流程，AI 會讓輸入更豐富。如果團隊習慣以狀態取代檢視，AI 會讓狀態更快、更漂亮。

貫穿案例：B2B LMS 與 email 提醒

在本系列的所有文章中，我都保留同一個例子：一個 B2B LMS 平台，大型客戶為員工指派必修課程，而團隊為未在期限前完成必修課程的人新增 email 提醒。這個案例很好地顯示，AI 改變的不是某一場特定會議，而是整條團隊注意力的鏈條。

在 refinement 中，AI 協助蒐集客戶脈絡、相似請求、指派狀態、通知架構，以及關於時區、去重、語言設定與歷史紀錄的問題。團隊能更快得到有意義的 backlog item。但團隊仍然必須決定什麼算未完成的課程、如何處理 expired、第一版的界線在哪裡，以及哪些資料不能交給模型。

在 planning 中，AI 協助蒐集幾種 Sprint Goal 與工作範圍的選項：最小、擴充、積極、範圍外。團隊能更快看見取捨。但團隊仍然必須誠實回答，什麼才真的放得進衝刺、什麼支持 Sprint Goal、什麼可以最先拿掉，以及 Definition of Done 的風險藏在哪裡。

在 Daily Scrum 中，AI 提出訊號：scheduler 的 PR 已開啟但沒有 review、QA 在等測試資料、聊天中討論過重複的風險、時區方面出現了不確定性、支援團隊帶來了新的客戶問題。這是很好的輸入。但團隊自己決定 Daily 之後需要同步誰、要升級哪個風險，以及如何調適接下來的計畫。

在 Sprint Review 中，AI 收集結果與回饋：提醒發給了誰、open/click rates 如何、支援收到了哪些工單、試點客戶說了什麼、哪些 backlog items 與這個 Sprint Goal 相關。但產品價值只有在 Scrum Team 與利害關係人決定接下來要做什麼時才會出現：釐清 eligibility、調整 backlog、為支援新增診斷，或重新檢視優先順序 expired。

在 Sprint Retrospective 中，AI 協助看見團隊又一次太晚拿到測試資料、review 卡在相似的地方、Definition of Done 在不同角色之間隱性地出現分歧，而上個衝刺的 action item 沒有被完成。但改善只有在團隊為下個衝刺選定一個具體實驗時才開始：例如事先固定測試資料的 owner、縮小 PR 規模，或釐清含 email 寄送任務的 DoD。

同一個案例顯示了重點：AI 可以把事實的線索貫穿整個衝刺。但它無法取代讓這些事實變得有用的那些決策。

AI 加速的五種反模式

AI 最令人不快的不是它有時會出錯。錯誤可以被抓出來。最令人不快的是，它能把糟糕的流程做得非常有說服力。

虛假的清晰。 在 refinement 中，團隊看到一份工整的 user story、詳細的 acceptance criteria 和一份 edge cases 清單。看起來任務很清楚。但如果事實無法追溯到來源，而開放問題被藏在平滑的文字底下，團隊只是更快地製造了準備就緒的假象。

虛假的真實感。 在 planning 中，模型彙整出一份漂亮的 Sprint Plan：目標、scope、依賴、risks、steps、estimates。但如果開發者沒有檢查 capacity、DoD、未完成的工作和真實限制，這就不是計畫。這是一份包裝精美的希望。

狀態機器人。 在 Daily Scrum 中，AI 每天寫出誰做了什麼、Jira 有什麼變動、哪些 PR 已開啟。這很方便。但如果團隊不再談論 Sprint Goal 和計畫最近的調整，Daily Scrum 就變成了報告。

演示劇場。 在 Sprint Review 中，AI 準備簡報、release notes 和回饋摘要。一切看起來都很專業。但如果利害關係人不爭論、Product Backlog 沒有改變，而不舒服的訊號被平均掉，團隊就只是做了一場簡報，而不是 Review。

沒有改變的回顧。 在 Retrospective 中，AI 提出 root causes 和 action items。但如果人們不願意誠實發言、如果沒有 owner、沒有對效果的檢驗，也沒有在下一個 Sprint Backlog 中留下位置，這就不是 improvement。這是一份沒有改善的改善紀錄。

這五種反模式都有同一個本質：AI 降低了形式的成本，但形式開始假裝自己是內容。正因如此，系列文章裡才這麼常重複引用關於 overreliance、confabulation、misinformation、information integrity、privacy 和 human oversight 的來源： NIST AI Risk Management Framework 1.0, NIST Generative AI Profile 和 OWASP Top 10 for LLM Applications 2025 在 AI 系統層級很好地描述了這些風險類別。在 Scrum 團隊中，它們表現得非常具體：就是對漂亮草稿的過度信任。

團隊中什麼應該變得更強

如果 AI 加速了準備工作，團隊可能會誤以為自己需要更少的紀律。實務上恰恰相反。草稿產生得越快，檢驗的紀律就越重要。

我會指出五項團隊能力，它們變得更重要，而不是更不重要。

第一：把事實與假設分開。 在任何 AI 輸入中都應該看得出：什麼來自來源、什麼是模型的詮釋、什麼是工作假設。這在 refinement、planning 和 Review 中尤其重要，因為錯誤很容易變成 backlog item 或產品決策。

第二：不僅檢查完整性，也檢查貌似合理的平滑。 好的 AI 草稿 reviewer 問的不是「還要加什麼？」，而是「這裡什麼可能是錯的？」、「哪個依賴可能從摘要中消失了？」、「模型把哪個不舒服的訊號平均掉了？」。

第三：不要把 AI 訊號當作對人的評價。 Daily Scrum 和 Retrospective 對這條界線尤其敏感。如果模型讀取 Jira、Git、PR comments 和聊天，很容易從分析工作滑向隱性 monitoring。這會破壞信任，讓對話變得更謹慎。實務上這意味著：分析 work and system，not people。

第四：指派檢驗的擁有者。 商業意義由產品負責人檢驗。需求的連貫性由分析師檢驗。架構限制由開發者檢驗。Testability 和 failure modes 由 QA 檢驗。UX 界線由設計師檢驗。會議品質和團隊共識由 Scrum Master 檢驗。AI 可以準備一份共同草稿，但不能是檢驗的擁有者。

第五：把決策貫徹到工作的改變。 如果 Sprint Review 的結果沒有改變 Product Backlog，而 Sprint Retrospective 的結果沒有產生可檢驗的 next-sprint experiment，AI 可能協助了文件，但未必協助了 Scrum。

釋放出來的時間該用到哪裡

這個系列最重要的問題之一其實不是技術問題。如果 AI 幫團隊節省了準備時間，這些時間去了哪裡？

糟糕的答案：立刻用更多任務把它填滿。這樣一來，AI 只是提高了流量密度，掩蓋了過載。團隊更快準備任務、更快彙整計畫、更快寫狀態、更快產出會議紀錄，但對決策品質並沒有變得更用心。

更成熟的答案：把一部分釋放出來的時間，投入到過去總是輸給急迫性的事情上。檢查有爭議的客戶脈絡。釐清 Definition of Done。補齊測試資料。拆解反覆出現的 review 問題。改善文件。減少技術債。老實說，在複雜的 planning 之前好好睡一覺。

AI 有用的時候，不是團隊單純做得更多。它有用的時候，是團隊開始少花注意力在複述顯而易見的事，多花注意力在過去因為噪音而被延後的決策上。

在 Scrum events 中導入 AI 的實務做法

如果團隊問我該從哪裡開始，我不會從一個宏大的「Scrum 的 AI 轉型」開始。我會從一張小小的活動準備地圖開始。

在把 AI 導入每一場會議之前，值得先回答七個問題：

  • 在這場會議中，什麼樣的輸入才真正有助於檢視與調適；
  • 哪些來源可以使用，哪些不行；
  • 事實、假設與模型的詮釋如何區分；
  • 誰來檢查業務、架構、測試、UX、資料與風險；
  • AI 可能放大這場會議的哪個反模式；
  • 什麼才算是在 AI 建議之上的 human override；
  • 團隊如何判斷這場活動變得更有用，而不只是更短。

最後一個問題特別重要。會議時長縮短本身並不證明有所改善。如果團隊不再調適計畫，Daily Scrum 可能變得更短也更糟。如果回饋消失了，Sprint Review 可能變得更漂亮也更薄弱。如果沒有人執行 action items，Retrospective 可能變得更整齊也更沒用。

所以我會看的不是「省了多少分鐘」，而是更鮮活的跡象：團隊更早看到風險、更少爭論事實、更能區分未知、在 Review 之後更常調整 Product Backlog、在衝刺內更誠實地調適 Sprint Backlog、在 Retrospective 之後選出更少但更具體的 improvement experiments。

所以真正改變的是什麼

AI 作為準備與分析層的放大器，改變了經典的 Scrum 會議。它更快彙整 refinement 的材料、planning 的計畫選項、Daily Scrum 的訊號、Sprint Review 的成果與回饋、Retrospective 的事實與模式。

但它不改變主要原則：Scrum events 的存在不是為了生產文件、狀態、demo 和會議紀錄。它們的存在是為了檢視與調適。如果 AI 幫助團隊更清楚地看見現實、更快走向有意識的決策，它就有用。如果 AI 只是讓舊儀式更順暢，團隊得到的不是 Scrum 的改善，而是舊問題的加速版。

所以我的最終結論是：在 Scrum events 中導入 AI，不該當作會議的替代品，而該當作人類檢視之下的準備層。讓 AI 彙整事實、提出選項、標示風險、提醒決策，並協助記錄 follow-up。但團隊必須保留 Scrum 之所以存在的那些東西：透明性、檢驗、調適、責任，以及誠實改變後續工作的能力。

成熟的團隊不會問：「我們現在可以砍掉哪些會議？」它會換個方式問：「AI 可以拿走哪一部分噪音，讓我們留下更多注意力給意義、價值、品質與行為改變？」這個問題比較不炫目。但它更接近跨職能開發團隊的真實工作。

來源與參考

← 所有隨筆