A Scrum Lecture
The Spirit of the Game
Marcus ｜ 2026-XX-XX
本場內容主要引自 Jeff Sutherland & James Coplien，《A Scrum Book: The Spirit of the Game》(2019)
1
一個具有自主性、跨專業能力的團隊，
為了一個共同的目標，
透過討論與協商決定怎麼做，
並在每兩週交出一個可被檢驗的價值增量。
我們已經跑了一年的 Scrum
每兩週的 Sprint Planning
每天的 Daily Scrum
Sprint Review
Retrospective
Product Backlog
Sprint Backlog
Sprint Goal
Refinement
估點 / Story Point
Velocity
Definition of Done
Linear 上的完整追蹤
但是我們卻遇到了一些問題。
但是我們遇到了這些問題
Scrumfall
流程變成「安排 Design、開發、測試、交付」，披著 Scrum 外皮的 Waterfall 循環
估點是為了 deadline
所有的估時、估點，最後都是為了確保上線時間。估點變成工期。
很少 negotiate 更快的路
很少討論「有沒有更簡單、更快的方法達成」，中間產生了浪費
Planning 之後才發現還沒 ready
Planning 結束時專案還沒真正 ready，開發後 scope 與估點持續膨脹
做好的元件沒有被再用
去年做完的 notification system，至今沒有被使用過。
我們交給團隊的不是一個目標，
是一份有截止日的施工圖。
是一份有截止日的施工圖。
我們同時固定了兩件事：什麼時候要好，以及要怎麼做。
那剩下能被壓縮的，就只有品質和人。
那剩下能被壓縮的，就只有品質和人。
"a Vice President might demand a fixed date and scope, creating constraints that the team cannot satisfy. This will likely lead to unintended consequences such as poor quality or burnout." — ¶1 The Spirit of the Game
一個具有自主性、跨專業能力的團隊，
為了一個共同的目標，
透過討論與協商決定怎麼做，
並在每兩週交出一個可被檢驗的價值增量。
什麼叫一個好的「共同的目標」？
目標有四層
Vision我們最終要讓使用者的生活變成什麼樣子
Marcus 與管理層
年
年
Product Roadmap從現在到那裡，會經過哪些階段
Marcus 與 PO
季
季
Release Plan這一版要讓使用者拿到什麼
PO
版本
版本
上面是我的工作 ／ 下面是我們的工作
Sprint Goal這兩週要交付什麼價值
整個 Scrum Team 一起訂
兩週
兩週
Sprint Goal：以前與現在
以前的寫法
完成 Reflection 的輸入畫面、歷史列表、
編輯與刪除，以及與 Journal 的串接
編輯與刪除，以及與 Journal 的串接
你只能檢查：做完了幾張卡
應該的寫法
讓完成一次專注的使用者，
願意在離開 App 之前
留下一句對這次專注的回顧
願意在離開 App 之前
留下一句對這次專注的回顧
你可以檢查：完成專注的 session 裡，留下回顧的比例
同一個目標，這些全部變成可以討論的：
一個小輸入框，還是一個完整頁面？
先只做「當下這一次」，歷史列表下個 Sprint 再說？
編輯與刪除這一版先不做？
先用最小版本 A／B test 驗證採用度，再決定完整解法？
這兩種寫法，核心交付的價值可能一樣；
差別是第二種讓團隊有十種方法達成，第一種只有一種。
差別是第二種讓團隊有十種方法達成，第一種只有一種。
什麼是一個好的 Sprint Goal
1
可以判斷「達成了沒有」，不是「做完了幾張卡」
如果 Sprint 結束時你只能回答「做完了幾張」，那它不是目標。
2
說結果，不說路徑
它描述使用者至少能做到什麼，不描述我們要蓋哪些畫面。
3
值得整個團隊兩週一起 focus
兩三天就能結束的，不是 Sprint Goal，是一張卡。
4
拿掉兩到三成的 planned scope，它還成立嗎
如果必須百分之百做完才算達成，這個目標太脆弱。
"The Scrum Team commits to a short statement of the value it intends to create during the Sprint." — ¶71 Sprint Goal
"The Scrum Team should commit to the Sprint Goal as something always within reach." — ¶71 Sprint Goal
Goal 是承諾。
清單是預測。
清單是預測。
"The Development Team commits to the Sprint Goal." — ¶71 Sprint Goal
"Note that the Scrum Team commits to the Sprint Goal and not their forecast delivery." — Notes on Velocity
"The contents of the Sprint Backlog can change during the Sprint. … incremental replanning as a major activity of the Daily Scrum." — ¶72 Sprint Backlog
整個 Scrum Team 的工作，是接住這個承諾——
不是做完那張清單。
不是做完那張清單。
Goal 定了之後，團隊要問的不是——
「清單上還剩哪幾張？」
而是——
這兩週我們能做出什麼，
讓這個 Goal 成立？
讓這個 Goal 成立？
那個東西，就是這個 Sprint 的價值增量。
一個具有自主性、跨專業能力的團隊，
為了一個共同的目標，
透過討論與協商決定怎麼做，
並在每兩週交出一個可被檢驗的價值增量。
一個價值增量，是一個
可以被使用、可以被檢驗的完整成果。
可以被使用、可以被檢驗的完整成果。
可以被使用使用者真的能從頭走到尾，不是我們內部才看得到
可以被檢驗有人可以判斷它成立或不成立，不是「做了八成」
完整它符合我們對「完成」的定義，不是等下個 Sprint 補
進度 80%
一個真的存在的東西
怎麼切：不是重做，是其中一部分
不是這樣
每一次都要把上一次做的丟掉重做。
我們有一個累積多年的產品，不能這樣工作。
我們有一個累積多年的產品，不能這樣工作。
也不是這樣
這個 Sprint 做後端，下個 Sprint 做前端。
工程上每一塊都完整，但使用者一塊都用不到。
工程上每一塊都完整，但使用者一塊都用不到。
是這樣
從一開始就是同一台車，每個階段都是能開的。
每次做的那一部分，穩定、可用、不會被丟掉。
每次做的那一部分，穩定、可用、不會被丟掉。
它不是做了幾張票，或是進度百分比，而是一個完整的價值單位。
目標固定。做法可以談。範圍可以談。
因為我們承諾的是這兩週要交付的價值，不是一份實作清單。
做法
同一個結果，可以換一種實作、換一個已經做好的元件，或先用最小版本驗證。
範圍
這一版做到哪裡、哪些留到下一個 Sprint。
順序
先做讓 Goal 成立的那一塊，其餘往後排。
"The Scrum Team can use the Sprint Goal to frame the selection of PBIs for the Sprint but in some sense the Sprint Goal is more important even than the sum of the individual PBIs." — ¶71 Sprint Goal
"But it is sometimes possible to complete the Sprint Goal (in some way) without completing all SBIs." — ¶71 Sprint Goal
但有一件事，不在可以談的清單上。
品質不能談。
因為品質不是一個選項，它是 Definition of Done。
如果 code review 是我們 Definition of Done 的一部分——那再怎麼趕，它就是必須被做完。
如果 寫測試 是 Definition of Done——那就必須有。
如果 符合 Design System、UI 達到我們的水準 是 Definition of Done——那也不能被拿掉。
"If the work does not conform to Definition of Done, the work is then by definition not Done, and the team may not deliver the corresponding Product Backlog Item." — ¶82 Definition of Done
如果同時固定日期和做法，
那唯一能夠被壓縮的，就只剩下品質和人。
那唯一能夠被壓縮的，就只剩下品質和人。
每兩週，我們交出去的不是進度，
是一個真的能用的東西。
是一個真的能用的東西。
怎麼切、切多窄——可以談。
切出來的東西是不是真的完成了——不能談。
那，我們該怎麼找到這條路？
一個具有自主性、跨專業能力的團隊，
為了一個共同的目標，
透過討論與協商決定怎麼做，
並在每兩週交出一個可被檢驗的價值增量。
從願景到增量，價值是如何產生的？
從山頂到船上
Vision 不會自己走到使用者手上。
中間這一整條河，就是 Scrum 在做的事。
中間這一整條河，就是 Scrum 在做的事。
Vision
確定、遙遠、不動
Product Roadmap
外在因素在這裡匯進來
Product Backlog
大小不一，還沒整理
Refinement
大貨物切成一樣大的小貨物
Value Team
Activation Team
Ops Team
每一格是一個 Sprint
Review
過了這道門才算數
每一箱都是一個 Increment
彼此分開，但上同一艘船
協商是整個團隊找到最能交付價值的過程
它發生在整條路上。
協商是整個團隊找到最能交付價值的過程
它發生在整條路上。
協商「為什麼要做」和「做什麼」
把不確定性在這裡解決掉，不要帶進 Sprint。
Refinement：協商「為什麼要做」和「做什麼」
這場會要做到的 —— 讓工程在動手之前，就已經開始想這件事怎麼做。
1
這件事要解決誰的什麼問題。
講到工程能自己說一遍，不是聽懂就好。
2
做到什麼程度算完成。
主要流程和 AC 要講清楚。每個 edge case 不用。
3
最不確定的地方在哪裡。
每張卡問一次：這裡面最可能出事的是什麼？答不出來的那張，通常就是它。
4
那塊不確定，要不要先花時間查。
該做 spike 就排進去。別讓它在 Sprint 第八天才炸。
5
這張卡是不是太大。
前兩三個 Sprint 的卡，單張不該超過一個 Sprint 開發量的一成。
6
估點和順序要不要更新。
知道的事變了，估算就該跟著改。有依賴、有外部時程的，現在調比在 Planning 調便宜。
¶64 PO 佔用工程的時間，總量不該超過工作時間的一成，而且要事先排。不是 PO 想到就找人。
"The main purpose of bringing the team together to refine the backlog may be to get the team to start thinking about how to implement the envisioned features." — ¶64 Refined Product Backlog
走出這場會：大家講的是同一件事，卡切到可以動手，剩下不知道的都攤在桌上。
協商是整個團隊找到最能交付價值的過程
它發生在整條路上。
協商「為什麼要做」和「做什麼」
把不確定性在這裡解決掉，不要帶進 Sprint。
協商 Sprint Goal，和每一條的做法與範圍
直到團隊自己有把握，這兩週做得完。
Sprint Planning：協商 Sprint Goal，和每一條的做法與範圍
這場會要做到的 —— 定出這兩週要達成什麼，然後一起找出達成它的路。
1
這兩週要達成什麼。
一句話。而且兩週後要能判斷有沒有達成。
2
有哪幾條路可以達成它。
至少兩條。只有一條的時候，你在報告，不是在協商。
3
每一條卡要做到哪裡。
哪一段是 Goal 需要的，哪一段是順手做的。後者現在就標出來。
4
哪些先做。
先做讓 Goal 成立的那一塊。其他往後排。
5
做得完嗎。
這題只有工程能回答。門檻不是「有把握」，是說得出怎麼做到、以及怎麼知道做到了。
¶24 兩週的 Sprint，這場會抓四小時以內。真的超過就超過，但要回頭問為什麼。
"This requires that the Scrum Team do a detailed enough design of the solution to have a high degree of confidence about how to build the product, and requires that team members feel they can complete their work plan during the Sprint." — ¶24 Sprint Planning
"What other alternatives have you considered?" … "Develop many options in parallel, fixing only the critical constraints up front." — ¶42 Set-Based Design
走出這個會，團隊要有信心說出：這兩週我們完成得了這個 Sprint Goal。
說不出來，就是還沒談完。
Sprint 開始之後，協商沒有停
每天重新規劃一次。先確保 Goal 達得到，其次才是卡片做得完。
常見的問法（書上說這是一種做法，不是規定）
昨天做的，讓我們離 Goal 更近了嗎。
不是報進度。做了多少不重要，離目標近了沒有才重要。
今天做什麼，最能推進 Goal。
順序每天重排一次。
有什麼擋住了。
說出來就好。不要在這裡解。
當場可以談的
改順序。
¶29 每天至少換一次順序，才擺脫得了平庸。
卡片增刪拆併。
¶72 Sprint Backlog 在 Sprint 中被改，是正常的。
換打法，而不是砍範圍。
¶32 順序是：先換做法，再找人幫忙，最後才減範圍。
真的達不到，找 PO 重談 Goal。
¶71 會後去談。前提是真的達不到，不是想少做。
這是重新規劃的會，不是解問題的會。發現問題，會後找相關的兩三個人解掉，隔天回報。十五分鐘結束。
這是 Development Team 自己的會，其他人受邀才來。
這是 Development Team 自己的會，其他人受邀才來。
"Have a short event every day to replan the Sprint, to optimize the chances first of meeting the Sprint Goal and second of completing all Sprint Backlog Items." — ¶29 Daily Scrum
每天的 Daily Scrum，就是一次小的 Planning。
重新對準目標，然後挑今天最可能達成它的那條路。
重新對準目標，然後挑今天最可能達成它的那條路。
協商是整個團隊找到最能交付價值的過程
它發生在整條路上。
協商「為什麼要做」和「做什麼」
把不確定性在這裡解決掉，不要帶進 Sprint。
協商 Sprint Goal，和每一條的做法與範圍
直到團隊自己有把握，這兩週做得完。
Definition of Done 不能談
能談的是：這個版本，現在要不要交出去。
協商不是為了少做一點。
是為了找到更好的做法。
是為了找到更好的做法。
目標不動，路徑先變，範圍最後才動。
發現得越早，能換的路越多。
而每一次認真找路，都在替下一次累積積木。
發現得越早，能換的路越多。
而每一次認真找路，都在替下一次累積積木。
但這一切有一個前提：什麼樣的團隊，才有辦法這樣協商？
一個具有自主性、跨專業能力的團隊，
為了一個共同的目標，
透過討論與協商決定怎麼做，
並在每兩週交出一個可被檢驗的價值增量。
一個自主的跨職能團隊——重點在「自主的」。
而「自主」，到底是什麼意思？
自主，是三件事同時成立
不是被授權就叫自主。
自主團隊
承擔目標、完成目標
能力可以培養，權力可以授予，當責只能自己選。
三個缺一個，中間那塊就不成立。
缺一個角，會發生什麼事
缺哪一個角都一樣。最後都會回到同一件事：
要有人先把答案寫好，我們才動得了。
那就是 Waterfall。而它會回來，不是因為我們選了它，是因為三個角缺了一個。
一個自主的團隊，日常長什麼樣
對 PD「這個 flow 要做三步。我記得之前做過很像的東西。」
「我跟 PD 對過了，沿用那個做法，設計改一點就成立。三天變一天半。」
對 PO「這次要做的，跟後面那幾個需求有一大半一樣。」
「範圍砍掉一部分，剩下的我做成之後可以重複用的。這個 Sprint 多花兩天，後面三次不用再做。」
對 PO「做到一半發現第三方的限制跟文件不一樣，照原本做法做不完。」
「我想了兩條路。走 A 的話 Goal 一樣達得到，B 功能留到下個 Sprint。你選一條。」
"The Scrum Team commits to a Sprint Goal, and there are multiple ways to achieve it."
— ¶76 Developer-Ordered Work Plan
一個具有自主性、跨專業能力的團隊，
為了一個共同的目標，
透過討論與協商決定怎麼做，
並在每兩週交出一個可被檢驗的價值增量。
Next Steps
會爆的地方，
在進 Sprint 之前就攤開。
在進 Sprint 之前就攤開。
散會的時候，每個人都相信
兩週達得到 Sprint Goal。
兩週達得到 Sprint Goal。
這個 Goal，達成或沒達成。
沒有第三個答案。
沒有第三個答案。
"Having pride means working to your own standard of quality and taking ownership of the results."
— ¶38 Product Pride