Scrum 流程整理：三個角色、三個產出物、五個事件，從 Backlog Refinement 到 Retrospective

換到新團隊後，開發流程改成用 Scrum 運作。剛開始參加會議時，很容易只記得「每天早上要站會」、「每兩週要 Demo 一次」，但說不清楚每個會議為什麼存在、結束時應該產出什麼。這篇照著一個 Sprint 的順序把流程整理一遍，順便對照 Scrum Guide 2020，修正一些網路上常見、但其實是舊版或誤解的說法。

全貌：3 個角色、3 個產出物、5 個事件

Scrum 的東西不多，記住下面這張表就有完整的骨架：

Product Backlog Refinement 不在五個事件裡。Scrum Guide 把它定義成一個持續進行的活動，很多團隊會固定排一個會議來做，但它不是必須的事件。

2020 版的幾個改動

網路上很多文章還是 2017 版以前的寫法，對照時要注意：

• 「開發團隊」改成「Developers」：以前的說法是 Scrum Team 裡面還有一個「Development Team」，2020 版拿掉了這層，Scrum Team 就是一個團隊，裡面有 PO、Scrum Master 和 Developers，避免 PO 和開發人員變成「兩邊」
• 每個產出物都有對應的承諾：Product Backlog 對應 Product Goal、Sprint Backlog 對應 Sprint Goal、Increment 對應 Definition of Done。產出物說明「有什麼」，承諾說明「要達到什麼」
• Sprint Planning 從兩個主題變成三個：多了「Why」，也就是先說清楚這個 Sprint 為什麼有價值
• Daily Scrum 不再規定三個問題：「昨天做了什麼、今天做什麼、有沒有阻礙」變成可選的形式，重點改成檢查離 Sprint Goal 還有多遠

角色：誰負責什麼

Product Owner

• 負責管理 Product Backlog：根據市場需求、客戶反饋、商業目標，不斷新增、修改 User Story，並排列優先順序
• 和 Stakeholder（利益相關者）溝通，理解需求，再把需求轉成 Product Backlog 的項目
• PO 是一個人，不是一個委員會。其他人可以影響 PO 的決定，但要改變優先順序，得去說服 PO，而不是直接找開發人員插單

Developers

• 負責把 Product Backlog 的項目做成可用的 Increment，包含設計、開發、測試
• 決定怎麼做：技術方案、任務拆分、誰做哪一塊，都由 Developers 自己決定
• 對品質負責：每個 Sprint 的成果都要符合 Definition of Done

Scrum Master

• 不是專案經理，也不是 Developers 的主管，不分派工作
• 負責讓團隊理解並實踐 Scrum：引導會議、確保時間盒被遵守、排除團隊自己解決不了的阻礙
• 也要協助 PO，例如整理 Product Backlog 的方法、把 Product Goal 講清楚

Product Backlog Refinement

Refinement 的目的，是讓 Product Backlog 上方、接下來幾個 Sprint 可能會做的項目，在 Sprint Planning 之前就已經夠清楚，Planning 時才不會把時間花在釐清需求。

• PO 平常和 Stakeholder 討論需求，把需求轉成 User Story 和其他 Product Backlog 項目
• 開發團隊和 PO 定期一起討論 Product Backlog 中的項目，通常在每個 Sprint 內進行
• 開發人員會提出技術上的考量和建議，PO 則會澄清和修訂每個 User Story，確保它們準備好了
• 這個過程也包含對 User Story 做初步的規模估算（例如使用故事點），讓 PO 更好排序：同樣價值的兩個項目，成本低的通常先做

一個項目「準備好了」是什麼意思

很多團隊會定一個 Definition of Ready（Scrum Guide 沒有這個名詞，是業界常見的做法），常見的條件：

• 描述清楚：用「作為＿＿，我希望＿＿，以便＿＿」的格式寫出誰要用、要做什麼、為什麼
• 有驗收條件：例如「訂單金額為 0 時不能送出」、「庫存不足時顯示提示」，Sprint Review 時才有依據判斷做完沒有
• 大小適中：一個 Sprint 內做得完。太大的就拆，例如把「訂單管理」拆成「建立訂單」、「查詢訂單」、「取消訂單」
• 已估算：Developers 對大小有共識

拆 User Story 時，要盡量依功能切，不要依技術層切。「建立訂單的前端」、「建立訂單的 API」、「建立訂單的資料表」分開成三個 Story，任何一個單獨完成都沒有辦法給使用者用；「建立訂單（只支援信用卡）」和「建立訂單支援貨到付款」才是各自都有價值的切法。

參與者

• Product Owner（PO）
• Developers
• Scrum Master（可選，通常只在團隊需要引導時參加）
• 利益相關者或領域專家（可選，需要釐清需求時邀請）

2017 版 Scrum Guide 曾建議 Refinement 通常不超過 Developers 產能的 10%，2020 版拿掉了這個數字，但可以作為參考：Refinement 太少，Planning 會變成需求討論會；太多，會擠壓開發時間。

Sprint Planning

在每次 Sprint 開始時，會舉行 Sprint Planning 會議，整個 Scrum Team 都要參加。2020 版把它分成三個主題：

① Why：這個 Sprint 為什麼有價值

• PO 向團隊說明，如果這個 Sprint 完成，產品會多出什麼價值，比如「這次 Sprint 我們要讓用戶能建立訂單」，並說明背景和重要性
• 全隊討論後確定 Sprint Goal，Sprint Goal 必須在 Sprint Planning 結束前定下來

② What：這個 Sprint 做哪些項目

• PO 依優先順序提出項目，Developers 評估能不能在這個 Sprint 內完成
• Developers 依實際的開發能力對每個 User Story 估算，並參考過去幾個 Sprint 實際完成的量（Velocity），決定可以拉進 Sprint 的範圍
• 某些功能太複雜時，可以當場建議切分或調整範圍
• 這是預估（Forecast），不是保證。2020 版刻意不說「承諾完成這些項目」，團隊承諾的是 Sprint Goal

③ How：要怎麼完成

開發團隊將選定的 User Story 拆成具體的 Task，並討論如何分工。Task 通常會具體到一個人一天左右可以完成，而且可以互相並行。例如：

• User Story：「作為一個用戶，我希望能夠建立訂單，以便購買商品。」
• Task：
  1. 設計建立訂單的前端畫面
  2. 實作後端 API，處理建立訂單的請求
  3. 將訂單寫入資料庫
  4. 撰寫單元測試，確保訂單功能正確運作

這個步驟由 Developers 主導，PO 不決定怎麼做，但要留在現場：拆任務時常常會冒出「這個情況要怎麼處理？」的問題，這時候需要 PO 當場回答。很多文章說「PO 在這個階段不發言」，比較精確的說法是 PO 不主導技術決策，但要隨時能回答需求問題。

另外，Developers 不一定要在 Planning 就把整個 Sprint 的 Task 拆完。常見的做法是先把前幾天要做的拆細，後面的在 Sprint 中再細化。

產出

這個過程不需要額外的會議，它就是 Sprint Planning 會議的一部分。Sprint Planning 結束時，應該已經完成：

• 定義好的 Sprint Goal
• 明確的 Sprint Backlog（選擇的 User Story）
• 至少前幾天要做的 Task，以及團隊對分工和做法的共識

時間盒：一個月的 Sprint 最多 8 小時，Sprint 較短時通常等比例縮短，例如兩週的 Sprint 約 4 小時。

參與者

• Product Owner（PO）
• Developers
• Scrum Master（協助引導會議）

Sprint Goal

Sprint Goal 是一句簡短而清楚的描述，概括這個 Sprint 要實現的主要成果。它應該回答「這個 Sprint 結束時，團隊要交付什麼價值」，而不只是列出任務或功能細節。

1. 簡潔明了：用一兩句話概括，而不是一份工作清單
2. 聚焦於價值：表達這次 Sprint 要交付的業務價值，而不是技術細節
3. 可衡量：Sprint 結束時，團隊能清楚判斷目標有沒有達成

例子

以電商的訂單管理系統為例，假設這次 Sprint 的主要工作是「作為一個用戶，我希望能夠建立訂單」，Sprint Goal 可以寫成：

讓用戶能夠成功建立訂單並保存到系統中，開始購物流程。

這個 Sprint Goal 沒有描述技術細節（例如設計 API 或連接資料庫），而是強調要交付的業務價值。

對照幾個不好的寫法：

Sprint Goal 的作用

1. 集中團隊精力：讓團隊知道這個 Sprint 最重要的是什麼，避免每個人各做各的 Story
2. 衡量進展：Daily Scrum 時檢查是否朝 Sprint Goal 前進，Sprint 結束時評估是否達成
3. 保留彈性：開發中發現某個 Story 比預期複雜時，Sprint Goal 是判斷依據。只要不影響 Sprint Goal，Developers 可以和 PO 協商，把部分範圍移出這個 Sprint；反過來，如果拿掉某個 Story 會讓 Sprint Goal 無法達成，就要優先處理它

第 3 點是 Sprint Goal 最實際的用處：沒有 Sprint Goal，所有 Story 看起來都一樣重要，遇到變數時只能每個都做一點，最後每個都沒做完。

Sprint Backlog

Sprint Planning 會議後產出的 Sprint Backlog 包含三個部分：

• Sprint Goal（Why）
• 從 Product Backlog 選出來的項目（What）
• 完成這些項目的執行計畫，也就是拆出來的 Task（How）

Sprint Backlog 是 Developers 的，而且在整個 Sprint 中會不斷更新：做的過程中發現漏掉的 Task 就加上去、Task 完成就移到完成欄。團隊通常會用看板（待辦、進行中、完成）或燃盡圖讓進度一目了然，Daily Scrum 時也是看著它討論。

Sprint

Sprint 是 Scrum 框架的核心，它是一個固定的開發週期（1 到 4 週），在固定的時間內完成一組選定的 User Story，交付可用的產品增量。Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective 都發生在 Sprint 裡面，一個 Sprint 結束後，下一個立刻開始。

1. Sprint 開始

• 開始點：Sprint Planning 是 Sprint 的第一個事件。Planning 結束時，團隊已經確定要完成的 User Story，並拆出了 Task
• 目標：達成 Sprint Goal，並盡可能完成 Sprint Backlog 中的工作

2. 每日站會（Daily Scrum）

• 頻率：每天一次，固定 15 分鐘，在同一個時間、同一個地點，減少協調成本
• 參與者：Developers。Scrum Master 負責確保會議有舉行、不超時，但不一定要出席；PO 如果也在做 Sprint Backlog 上的項目，就以 Developer 的身分參加
• 目的：檢查離 Sprint Goal 還有多遠，必要時調整接下來一天的計畫

最常見的形式是每個人輪流說「昨天完成了什麼、今天要做什麼、有沒有遇到阻礙」，但 2020 版已經不規定這個格式。輪流報告最常見的問題是變成向主管報告進度，每個人講自己的事，沒有人在看整體。比較好的做法是看著 Sprint Backlog 的看板，從最接近完成的項目開始討論：「這張卡還差什麼？誰可以幫忙？」

站會不是解決問題的會議。發現問題時，記下來，站會結束後由相關的人留下來討論，其他人回去工作。

3. Sprint 進行中的工作

• 持續開發：Developers 專注於 Sprint Backlog 中的 Task，並把功能整合到產品中
• 工作方式：根據 Daily Scrum 的調整推進 Task，處理 Bug、撰寫測試，並和其他成員協作完成所有 Story
• 自我管理：團隊自主決策和分工，Scrum Master 在團隊遇到自己解決不了的阻礙時協助排除
• 持續 Refinement：Sprint 中段通常會安排一次 Refinement，為下一個 Sprint 準備好候選項目

4. 產出可用的產品增量（Increment）

• 完成的定義：每個 Sprint 都要產出至少一個可用的 Increment，而且必須符合 Definition of Done（DoD）。沒有符合 DoD 的工作不算 Increment，也不能在 Sprint Review 中展示成「完成」
• DoD 的例子：程式碼經過 Code Review、單元測試通過、部署到測試環境、PO 驗收過驗收條件。DoD 是整個團隊的品質標準，每個項目都一樣適用
• 不一定要等到 Sprint 結束：Increment 可以在 Sprint 中隨時交付、甚至直接上線，Sprint Review 不是唯一的發布時機

DoD 和前面的驗收條件不一樣：驗收條件是單一 Story 的功能要求，DoD 是所有項目都要達到的品質門檻。

5. Sprint Review（衝刺檢視會議）

• 時間點：在 Sprint 的最後，一個月的 Sprint 最多 4 小時，兩週的 Sprint 大約 2 小時
• 參與者：Scrum Team 和 PO 邀請的利益相關者
• 內容：
  • 團隊展示完成的 Increment，說明實際的功能
  • 一起討論這段時間環境有什麼變化（市場、使用者回饋、預算）
  • PO 和利益相關者給出反饋，根據反饋調整 Product Backlog
• 目的：檢視成果、收集反饋，決定接下來最值得做的事

Sprint Review 是工作會議，不是單向的 Demo。如果每次都是團隊展示、台下說「很好」就散會，Product Backlog 沒有任何調整，這個會就沒有發揮作用。

6. Sprint Retrospective（衝刺回顧會議）

• 時間點：Sprint Review 之後，是 Sprint 的最後一個事件。一個月的 Sprint 最多 3 小時，兩週的 Sprint 大約 1.5 小時
• 參與者：整個 Scrum Team，包含 PO、Scrum Master 和 Developers
• 內容：
  • 討論 Sprint 中做得好的地方、遇到的問題，涵蓋人、互動、流程、工具和 Definition of Done
  • 提出具體的改進行動，最重要的那一兩項可以直接放進下一個 Sprint 的 Sprint Backlog
• 目的：持續改進團隊的工作方式，提高效率和品質

Retrospective 最常見的失敗是「每次都講一樣的問題，但什麼都沒改」。改進行動要具體、有負責人、下次 Retrospective 檢查，例如「Code Review 平均要等兩天」對應的行動是「每天下午 2 點固定看一次 PR，由輪值的人提醒」，而不是「大家要多注意 Code Review」。

Sprint 的核心特點

• 時間盒（Time-boxed）：每個 Sprint 都是固定長度，即使有未完成的工作也不會延長 Sprint。沒做完的項目回到 Product Backlog，由 PO 重新排序
• Sprint Goal 不變，範圍可以調整：Sprint 期間不能做出危害 Sprint Goal 的變更，品質標準也不能降低；但在不影響 Sprint Goal 的前提下，Developers 可以和 PO 協商、澄清或調整範圍。常見的說法「Sprint Backlog 完全不能改」並不精確，Developers 每天都在更新它
• 自我管理：Developers 在 Sprint 期間自己決定怎麼做，Scrum Master 協助排除障礙，PO 不干預具體實作
• 取消 Sprint：只有在 Sprint Goal 已經失去意義時（例如業務方向改變），PO 可以取消 Sprint，這種情況很少見

實務上常見的誤解

• 把 Scrum Master 當專案經理：由 Scrum Master 分派任務、追進度、對外承諾時程，團隊就不會自我管理。分工由 Developers 自己決定
• Daily Scrum 變成進度報告：每個人對著 Scrum Master 或主管講自己的進度，沒有人關心 Sprint Goal。要對著看板、對著彼此說
• 用故事點比較團隊或個人：故事點是團隊內部用來預估的相對大小，不同團隊的 1 點不一樣，拿來考核只會讓估算膨脹
• Sprint 中途插單：緊急的線上問題當然要處理，但如果每個 Sprint 都有大量插單，代表 Sprint 太長，或是需要預留處理臨時事項的產能，應該在 Retrospective 中討論，而不是默默加班
• 沒有 Definition of Done：每個人對「完成」的認知不同，有人寫完程式就算完成，有人要上線才算，Sprint Review 時才發現一堆項目其實沒做完
• Refinement 不足：項目沒有提前釐清，Sprint Planning 就會拖很久，或是 Sprint 開始後才發現需求不清楚

一句話總結

Scrum 用固定長度的 Sprint 把開發切成一段一段：PO 透過 Refinement 讓 Product Backlog 隨時準備好，Sprint Planning 決定為什麼做（Sprint Goal）、做什麼、怎麼做，Daily Scrum 每天檢查離目標多遠，Sprint Review 檢視產品、調整 Backlog，Retrospective 檢視團隊、調整做法；每個事件都是一次「檢視與調整」，而 Sprint Goal 和 Definition of Done 是讓這些檢視有標準可依的承諾。