近年來在符合Agile精神的各種專案方法論中，Scrum應該是最簡單，也是最熱門的。
雖然簡單，但要掌握其精神，必須對抗長久的習慣，而這並不容易。
目前市面上也衍生各式各樣Scrum架構的作法和細節，從一開始的User Story到sprint最後的檢討會議(retrospective)都有琳琅滿目的作法與工具。假如只能選一個最重要的精神，則「實況：瞭解事實」是最最最根本的Scrum精神。(註1)
Scrum架構中，理解事實有很多層面。在此以「角色」「衡量效率」「固定時間」作為範例。
1. 角色
實況(Scrum)只會有三種角色
1. 產品擁有人(Product Owner)
2. 團隊領導 (Scrum Master)
3. 團隊成員 (Scrum Team)
而最根本的Scrum務實精神，在角色所扮演的任務中展露無疑。
也就是：
(A) 只有產品擁有者，才能排定產品功能的開發順序(product backlog)！
(B) 只有團隊成員，才會決定每一段時間，哪些功能會完成！
換言之，什麼事情先做後做，交由最接近市場的人 - 也就是產品擁有人 - 來決定。但是那些事情要花多少時間，是由做事情的人 - 也就是團隊成員 - 來決定！這個作法完全奠基於事實，並且適用於絕大部分的情況。
這和傳統專案有很大的不同。許多專案的時間預估，都不是做這件事情的人來預估。自然就一定不可能預估的準確。
不過，在許多「精采的成功個案」中似乎常常會有一個超強的產品經理，能主導市場，產品進度，甚至使得專案團隊有突破性的創新結果：典型的個案就是第一代iphone直接由賈伯斯(Jobs)作為產品經理帶領開發。似乎就是產品擁有者，主導進度的鐵證？
然而，事實上絕大部分的產品經理都不是賈伯斯。可是，大部分的企業，卻可以雇用到接近賈伯斯擁有的研發團隊品質！！因此，絕大部分的情況下，將產品研發功能相關執行與時間預估，交由團隊成員，才比較可能產出和市場預期的結果。除非該產品經理很確信自己跟賈伯斯差不多，並且也能提出「具體證明」。（就如同大部分的資深程式設計師，都能提出具體的證明 - 程式碼，佐證他的經歷一樣)
2. 以結果來衡量團隊效率
在實況(Scrum)中，一個項目完成的定義就是「完成」。而團隊的速度，取決於每個sprint可以完成多少項目。當然團隊一開始的完成事項的速度，大概很難和自己預估的一樣。
然而，過了兩三個Sprint之後，團隊速度應該已經「固定」，而這個完成工作的速度，就變成「事實」。
要看研發團隊速度在這時候很簡單，打開燃盡圖(burndown chart)，算一下每段時間 - 例如每週或月 - 可以完成多少單位，自此之後，要估計時間，只要能有效估計每個功能(user story)規模大概多少單位即可。
這個事實，原則上不會改變。然而，產品擁有者確有權限可以在必要的時候改變事實。他有兩種選擇：(a) 更換產品功能。(b) 改變團隊。
更換產品功能可能是縮小功能規模。例如原本app支援facebook, linkedin, google+的帳號登入，考慮市場都在台灣，因此就先做facebook登入即可。
當然產品擁有者也可以改變團隊，重新組織團隊，更換成員。但一旦改變團隊，就必須重新啟動新的sprint，而也會重新產生新的速度。
3. 以取得事實來固定會議時間
Scrum(實況)的會議，必然鎖定會議「目的」以及「時間」。在事實的基礎下，兩者有很大的關聯。
以每日會議為例-- 不管是不是站著開會，一定是一天工作的開始，最多只花15分鐘。成員輪流以1-2分鐘「說明」三件事：
(a) 從上次開會到現在完成了什麼，沒有完成就說沒有
(b) 今天打算做什麼，而且有什麼會完成
(c) 遇到什麼困難需要ScrumMaster協助。
這三件事情，只是說明，若有問題，也是對說明的問題，絕不應該討論。要討論是開會之後，相關人等，聚集在適當的地方，最好是某個人的電腦前面，開始幫忙解決。
通常最容易花時間就是遇到困難的時候，大家紛紛都想提議見幫忙，但這並不是「這個會議的目的」。每天5-7人聚在一起，是為了將大家對狀況的認知統一，僅此而已。因為一旦開始討論困難，很有可能變成A和B熱烈的討論起來，其他5個人在滑手機發呆。Scrum Master要根據決定好的目的和時間，具體果斷的打斷討論，讓會議前進。
或許有些人會認為，這樣會破壞創造性思考和創意思維。然而，事實上無止盡的會議才是破壞創造性思考和創意的元兇。在每日會議之後，Scrum Master可以根據遇到困難的情況，重新找適當的人，並且到適當的地點 -- 也就是電腦前面，手腦並用的解決問題，而非在會議室空談。
其他在實況(Scrum)框架中的會議，像是Sprint啟動會議，Sprint結束會議，Sprint檢討回顧會議等等也都是一樣。必然是在特定的目的，特定的時間完成。
將能專注控制的事情完成，才能把時間與思維，留給創意。
註1. 因此，敏捷開發中的Scrum方法，中文翻譯應該叫做「實況」，至少也比google翻譯為「爭球」來的好。
註2. Scrum的學習可以參考這裡-> 學習Scrum，或者->Scrum認證
