首先，你要了解Scrum只有3種角色：產品負責人（Product Owner）、Scrum大師（Scrum Master） 和團隊成員。沒有業務分析師、技術主管或是資深Scrum大師；就只有以上3種角色組成能夠獨立提供價值的Scrum團隊。「團隊」是Scrum裡最小的組織單位，它要在很短的「衝刺」（Sprint）時期迅速為客戶提供價值。（本文摘自《SCRUM敏捷實戰手冊》，以下為摘文。）
產品負責人要決定很多事情：團隊要建造或創造的目標、提供哪些服務，或是設計、打造怎樣的流程。產品負責人的資料來自客戶、利害關係人、團隊本身，以及不論團隊做出什麼成果都能獲取價值的人；例如正在努力對抗農作物疾病的烏干達鄉村農民、正在開發自動駕駛汽車的工程師，甚至是進電影院觀看最近上映某部電影的電影迷。產品負責人必須從各種來源吸收資訊，其中有些資訊可能互相矛盾，但他還是得彙整出一套構想讓團隊得以執行。理出這些想法之後就是最困難的部分：產品負責人要按照價值排出各項任務的優先順序，從最有價值的事開始做。Scrum裡沒有所謂的「最優先的幾件事」（priorities），因為我們一次只處理一件優先事項，自然很難取捨，但這就是Scrum的工作方式。
所有工作事項都必須由產品負責人決定優先順序，從價值最高排到最低，並且建立「產品待辦事項清單」（Product Backlog）。這份清單列出團隊可以處理或解決的事項，而且這些項目可以無限延伸、不斷更動，也能因應客戶的回饋、市場條件、洞察觀點或管理上的不停變化。最終的目的就是要讓「改變」變得更容易。
然後，產品負責人在「衝刺規劃」（Sprint Planning）的會議上，向團隊展示產品待辦事項清單，團隊再根據清單決定下一段衝刺要解決哪些問題、可以完成多少工作。請注意，這些要由團隊決定，不是產品負責人或管理階層片面指定。團隊要把產品待辦清單的優先項目拉到「衝刺清單」；產品待辦事項清單可以持續更換輪替，但衝刺清單則是固定不變。衝刺清單上就是你希望團隊專注工作的項目，而且只有下一段衝刺要做的任務才會列在清單上。
接著，團隊就要開始賽跑。他們要進行一到四週不等的衝刺，時間的長短要配合團隊狀況選擇最佳的工作節奏。
最近，大部分企業都採用為期兩週的衝刺，不過我都推薦客戶以一週為限。原因是Scrum流程中本來就設有回饋的環節，所以我比較喜歡縮短循環週期，才能更迅速掌握狀況。
這樣的做法對於銷售、客服支援或財務等團隊尤其重要，因為這些領域都需要迅速的反應能力。
然後，還要安排每日Scrum會議，通常稱為「每日立會」（Standup），而且只需要花15分鐘。在這個會議中，團隊必須報告衝刺目標的工作進度、接下來的24小時內要完成什麼工作，以及即時反映可能妨礙團隊實現目標的任何因素。每日Scrum會議不必搞得正經八百，反而應該像是美式足球隊員圍成圓圈互相打氣、商討對策的小組會議，也就是簡短調整規劃的一小段時間。團隊在工作時一定會發現很多資訊，這正是大家分享前一天學到的新知的好機會。這就像一群人出去旅行，一定會先規劃行程路線，上路後，每天吃早餐時也會再查看地圖、天氣，或是確認輪到誰開車，接著才繼續上路。花個15分鐘討論一下，每日Scrum會議就結束啦。
現在，輪到Scrum大師登場！這個職稱很奇怪，對吧？其實我跟Scrum共同創辦人（也就是我爸）遊說了很久，建議改個名字，比方說「教練」。不過他說大家早就叫習慣了，現在要改已經太晚。喔，好吧，反正對於大多數企業，Scrum大師也是個新角色。他們的工作其實就是幫助團隊更有效率，「速率」（speed）就是他們膜拜的祭壇。
那麼為什麼要付錢叫他們來做這件事呢？因為他們要能讓你的團隊在同樣的時間內創造加倍的價值，那就值回票價了！讓你的團隊跑得更快，絕對比花錢雇用更多人或組成更多團隊來得好。所以，這位Scrum大師就是要幫助團隊提升速度（velocity），而產品負責人則是負責把成果變成「價值」。有些團隊真的很優秀，可以迅速做出成果，可惜那些東西沒人要；再也沒有什麼事情比這個更悲慘。大家還記得手機大廠Nokia吧？他們以前有幾支優秀的Scrum團隊，生產手機的速度非常快，結果iPhone一上市，就沒人想要Nokia手機了。他們原本可是手機市場的支配者，但才短短幾年市場價值就全部歸零。
所以，Scrum大師就像球隊教練一樣，協助團隊保持Scrum流程暢通，排除拖累團隊進度的障礙。這就是他們「每天」唯一的工作。
團隊進行衝刺清單任務的過程中，有時候需要坐下跟產品負責人討論，這個環節叫做「清單修正」（Backlog Refinement）。我認為這個環節就是Scrum的成敗關鍵。產品負責人要利用這段時間為之後的衝刺提供各種好點子，並且和團隊合作將這些構想付諸實行。還要明確決定這些項目有哪些工作必須執行，最重要的是要用什麼標準來判斷項目完成與否。
舉例來說，我常做的一件事就是在部落格上貼文。我可以很輕鬆的說：「我寫完了，可以貼出去囉！」可是真的這樣就完成了嗎？文章還需要編輯、校對，也許還要配張照片或圖片。然後，文章還必須放上網站，要有人按下「張貼」的按鈕。除非這些事情都能搞定，不然我光是寫一篇部落格文章也不會產生任何價值。最重要的是，要確保這些工作都能完成，不光只是做完個人負責的那一小部分。
判斷的標準可以很簡單，例如網頁上的圖片；但標準也有可能很複雜，例如植入性醫療器材團隊的專案，就必須符合美國聯邦食品暨藥物管理局（FDA）對人體安全的管理規定。所以，準備工作的重要性再怎樣強調都不為過，做好十足準備才能讓團隊生產力倍增。原因很簡單：如果工作項目不明確、品管標準也不清楚，團隊就要浪費許多時間釐清實際上要做什麼，而且還會常常發現必須等另一個團隊完成其他部分才能開始工作。
衝刺結束後，團隊和產品負責人要進行「衝刺檢視」（Sprint Review），向利害關係人和客戶展示已經完成的工作與成果。我要強調，這時要展示的是已經真正「完成」的工作，不是快要完成、幾乎算是完成的工作，也不是雖然還沒完成，但已經好努力、好認真、好拚命去做，所以要給一點掌聲的那種狀況。「已經完成」的工作就是已經完成了。然後，團隊和產品負責人要從參與會議的人獲取回饋意見：「我們喜歡這個」「我們不喜歡那個」「這樣做如何？」「我們現在看到這個，接下來我們真正想要的是⋯⋯。」產品負責人要利用這些回饋來重新安排產品待辦事項清單的優先順序，因為這些意見正是客戶真正需求的具體資訊，不是口頭上說說的想像而已。
軟體業界中有一條流傳已久的經驗法則，叫做「韓福瑞定律」（Humphrey’s law）：其實大家都不知道自己要什麼，等到看到自己不要的東西，才會知道自己要什麼。你要是叫他們寫下想要的東西，大概可以寫個數千頁沒完沒了，但是等到他們實際看到可以運作的實物，才會真正知道自己原來想要什麼。衝刺檢視的環節就是要展示一些有發表潛力的工作成果。它也許還不到足以正式上線的程度，或者還要完成更多工作才能發揮價值，但就算只是這麼一小塊，也是完完全全「已經完成」的工作，以後都不需要再調動。
衝刺檢視環節中要做的最後一件事就是，衡量團隊在衝刺期間完成的工作量，以及他們創造價值的速度，我們稱為「團隊速度」（Team’s Velocity）。這是Scrum的重要指標。我們要先了解團隊的速度有多快，才會知道能不能幫他們再加快速度，讓他們跑得更快。
各位要是回顧歷史，肯定會驚訝於一些扭轉未來的關鍵，往往只是無關緊要的小事。這就是俗語說的「少根釘子，王國慘敗」。第一次的衝刺檢視，就是如此攸關大局的小事。
當年，第一支Scrum團隊負責的是技術非常複雜的東西，所以不能照常把客戶找來看看團隊在做什麼。那時候我爸爸請來一些麻省理工學院（MIT）的專家。但這群人非常直截了當，不只質疑團隊的能力，還挑出好些基本缺陷和錯誤假設等。團隊因此受到相當大的打擊。我聽說過他們這一天過得非常慘，專家講完意見後，整個團隊垂頭喪氣，直想要放棄。他們都瞪著傑夫說，這種批評我們不能忍受，絕對會信心全失。
「好吧！」我爸爸回答：「那你們現在做出選擇，要當個跟大家都一樣的軟體開發團隊，或者想要成為最優秀的軟體開發團隊。我不能幫你們做決定。你們自己選吧！」
就在那一刻，這七個人的決定改變了世界，讓你可以讀到這本書，全世界有數百萬人得以使用更好的做事方法。歷史上像這種可以確定哪一天、哪個時候、哪些人做了哪些事的情況可不是太多，但Scrum就是在當時的那一刻誕生。
「好！」他們說：「我們再拚一次！」
接下來的故事大家都知道。
Scrum最後一個環節是「衝刺回顧」（Sprint Retrospective），檢討團隊的合作狀況。衝刺檢視是展示工作成果或提供服務的內容，衝刺回顧則是檢討這些成果或服務如何完成。產品負責人、Scrum大師和團隊要坐下來一起討論，確認哪些方面進展順利，哪些方面有待改進，以及團隊希望下一段衝刺該怎麼調整，讓工作變得更好也更快。檢討完以後，下一段衝刺才會開始。衝刺完之後再檢討、改進，不斷重複這樣的過程。
