一個壓力實驗：
有兩個籠子(A,B)，都連結同一個電極器，各有一隻老鼠。A籠子中，有一個燈號和按鈕，當燈號亮起時，如果在數秒內，A老鼠沒有按下按鈕，則就會產生高壓電極，讓A,B兩籠的老鼠都被電的很不舒服。不過，如果燈光亮了，在時間內A老鼠按下按鈕，則A,B兩籠就都沒事。B籠的老鼠則是全然被動的，只要A老鼠能做好他的工作，B老鼠就沒事。當然，經過幾次電極之後，A老鼠很快就學會了一旦看到燈亮，就應該儘速去按按鈕。
過一段時間之後，哪一隻老鼠的壓力大？
經過健康檢查，A老鼠幾乎看不到壓力大的特徵。而B老鼠，則出現各種癥狀：高血壓，胃潰瘍，成長障礙等等不一而足。
(以上內容取自:數位痴呆症：作者Manfred Spitzer)
軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難，而是在於自己「全然」隨著命運擺佈，無法控制。以A老鼠的情況來說，他仍然是被關著，而還得三不五時瞄一下燈是不是有亮，一旦亮了就得趕快反應。
然而，「至少有一件事情」A老鼠可以控制：他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。
Scrum(實況)是根據事實，固定的時間，以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內，每一個角色都有「至少可以全然控制」的事情，不但可以正確減低無法掌握命運的壓力，更能組合出正確的團隊合作方式。
Product Owner（產品擁有者或產品經理）
在傳統的「瀑布開發模式」，或者，系統整合商SI的「隨意無止盡需求模式」中，產品經理會就所有應該要做的事情列一個驚人的功能清單，交由專案經理負責領導開發。接下來的18個月，產品經理就在B老鼠的壓力下度過，即便有檢查，也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。
而過於認真擔憂的產品經理，更有可能在每一段時間，修改需求，讓開發團隊變成B老鼠，不確定哪個需求改變的命運降臨。
在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任，這個責任用非常簡單而清晰的方式減低他的壓力：「撰寫並排序需要完成的使用者情境」。
專案開始時，產品經理會撰寫數個使用者情境(user story)並且排定優先順序，而每個sprint開始時，團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後，檢查這些當初答應的story是否有如預期完成，並且在下個sprint開始時，或確定，或重新排列，或增加，或減少接下來要完成story的優先順序。
產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成，並且確定每sprint開頭都能選他最想要的事情先做完。因此，產品經理確實能掌握這個產品每一段時間的「樣貌」，而不是在最後關頭才求神拜佛，或者要求加班。甚至，在sprint的中間階段，若有必要，產品經理可以要求sprint停止，重新開始新sprint，用來調整後來才發現不正確的優先順序(priority)
Scrum Master (開發領導者)
過去一個團隊的技術領導者，帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理（或客戶）以及開發成員中的角色。
在傳統模式下，他若非變成一個技術獨裁者，用以壓迫成員前進並反抗大幅需求改變，就是變成試圖面面俱到的好好先生，用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description)，但事實上，困難的專案，不會因為一個很能講話的專案經理，就變得簡單。最後最常出現的結果是：專案經理總是能有效呈現「自己的貢獻和功能」，但無法反應在專案成功。換言之，常常看到自己從來不失敗的專案經理，曾經領導了很多壓根不成功的專案。
Scrum Master並非傳統的專案經理，其責任和角色也有很大的不同。而他能有效掌握的事情，也能讓他減少原本專案經理的壓力。
Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」：完成了哪些事情，接下來要做什麼，有遇到什麼困難。確保每個sprint開始的會議，領導團隊能完成哪些使用者情境(user story)，並且確定這幾個要完成的事情，產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情，但是透過掌握每一個sprint，腳踏實地的一個一個完成優先要完成的事項。
Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖，Scrum Master掌握過去真實進度。因而可以有效推測未來進度，並有足夠的證據顯示給產品擁有者。因此，才能有足夠的「動作權力」成為A老鼠：仍然在籠中，但掌握部分真實權力，以減少壓力。
Member (團隊成員)
傳統模式下，團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是：「某功能我們在要X月X日之前出來！」「現在馬上改做XX不然沒辦法驗收」。
而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。
但是，在Scrum中團隊成員，決定使用者情境：「真正完成的所需要的時間」。而這個權力，僅代表一個事實：由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做，只要決定現在在做的事情，什麼時候可以完成，以及「真的去做他」。換言之，Scrum團隊真正的A老鼠，其實只有團隊成員，只有他才會真正的按下按鈕。然而，如果Scrum團隊不能掌握分工負責的精神，團隊成員很快就變成B老鼠：不是被無謂的壓力掌握自己的命運，就是試圖跳脫牢籠。
