布魯克斯法則（Brooks's Law）
這個法則也挺有名的。指的是在一個進度已經落後的軟體專案中再增加人員，只會讓它更加落後。此法則來自於Fred Brooks 在1975年有名的書–《人月神話》。更多的人就如同名字所說的，只是代表更多的人，多不代表更好。事實上，更多的人需要更多的溝通管道，所帶來的是團隊效率的降低。保持小型的團隊就如同您應該將您的工作項目細小化。布魯克斯的書同時提出一個有名的問題，那就是「為什麼一個大型的軟體開發專案會延遲一年呢？」答案是：一天一天累積而成的。
帕金森法則（Parkinson's Law）
這個法則也經常被引用。指的是在工作能夠完成的時間內，工作量會一直增加，直到所有可用的時間都被填滿為止。Scrum對這個問題提供了一個好的解決方案，那就是持續地檢驗（Inspect）和調適（Adapt）。另一個改進的方法乃是採用敏捷心態的「如果不是現在做，要等到何時？ 如果不是我自願去做，那是誰？如果沒有做完，為什麼？（If not now, when？If not me, who？If not done, why？）」
學生症候群( The student syndrome）
與上述帕金森法則類似，指的是許多人會在最後的期限前才開始做該做的項目或者工作。如果您每天檢驗，您隔天便會發現問題。如果您每星期檢驗，您下個星期會發現問題。如果您每個月檢驗，您下個月才會發現問題。如果您只在專案結束後才回顧，您的專案應該是瀑布式專案。要改進學生症候群的現象，便是每天檢驗，也就是Scrum裏面的每日Scrum匯報（Daily Scrum）。
20-50-30定理( The20-50-30 Principle）
John Maxwell提出「根據經驗來說，20%的人會支持您的改變所付出的努力，50%的人也許還在觀望，剩下的30%會排斥改變。」「我們」─不管您是Scrum隊長（ScrumMaster）或者敏捷教練（擁抱和喜愛改變），是那20%的人。然而，改變對許多人來說並非一件簡單的事，我通常會讓那20%的人來幫忙推動改變，告訴或者展示敏捷Scrum所帶來的好處給那50%的人，同時幫忙那30%的人調整他們的心態。找出原因到底是「我不會做」或者「我不想做」。我們必須提供訓練讓大家知道如何去做，但是我們無法強迫每個人去做。記住，「指揮騎象的人，激勵大象，和規劃好道路（Direct the rider, motivate the elephant, and shape the path）」。（來自於Chip and Dan Heath 的書，《改變，好容易（Switch : How to Change Things When Change Is Hard）》）
Putt's Law
指的是科技被二種人主宰：一種是了解科技，但不是管理人員，以及另一種是管理人員，但不懂科技。「我們」─不管您是Scrum隊長（ScrumMaster）、敏捷教練或者講師，不是管理人員，所以我們是懂的人。
死亡行軍（Death march）
不是規則、法則或者定理，不過您應該常常聽到這個詞。來自於Edward Yourdon 著名的書《死亡行軍（Death march）》。在他的定義，所謂的死亡行軍專案是指「簡單來說，變數超出標準預期至少50%以上的任何專案」。其意思是當專案的期限、範疇和成本都是固定的時候，並且這些都只是要達成目標所需的一半時，代表團隊現在必須加班用雙倍時間來設法完成。Scrum不同的地方在於它打破了鐵三角定率（The iron triangle），其解決方法來自於改善團隊的速率，先專注在完成最大收益的工作，以及不停地改善流程。
The 1/10/100規則( The 1/10/100 Rule）
這個概念來自於品質控管。指的是如果您在早期可預防階段發現問題，您必須花一個單位（錢或者人工）來修復這個問題，如果是在可修復階段，就必須花十個單位，如果在無法彌補階段，那麼就必須花一百個單位來修復。套用在軟體或者產品開發的品質來說，如果一個缺點在需求階段被發現，您可以花一塊錢來修正它，如果在開發階段被發現，您得花十塊錢來修正它，如果己經在正式市場販賣的階段才被發現，您就必須花一百塊錢來修復。
如果您有在執行Scrum，您就會了解軟體測試的重要性。Scrum本身並沒有包括軟體開發的實際做法在裡面，然而我們應該是Scrum - 並且（Scrum-And）：我們執行Scrum並且結對編程（Pair programming）；我們執行Scrum並且自動化測試（Test automation）、測試驅動開發（Test-driven development）和持續整合（Continuous integration）。
別浪費錢在沒價值的地方，改變應該是免費的(Money for nothing, change is free)
由Jeff Sutherland所提出。別浪費錢在沒價值的地方指的是當成本超出其所產生的價值時，產品開發的動作就應停止，因為花錢去開發那45%沒有人會去用的功能是一種浪費，任何的浪費都是一種犯罪。改變應該是免費的，指的是您可以交換相同點數（Story points）的產品待辦項目（Product backlog items）。如此可以允許客戶和供應商之間對產品需求改變的合作，我們都知道在敏捷軟體開發宣言內提到：「回應變化重於遵循計畫」以及「與客戶合作重於合約協商」。
企業錯亂症候群( Corporate insanity）
一直做著重複同樣的事情，卻同時期盼不同的結果。仍然試著要將所有事情做完嗎？仍然試著要又快、又好、又便宜，三者都要嗎？仍然要所有產品功能在固定成本和期限內全部都做好嗎？是時侯要改變心態了，試著做一點不一樣的，看能不能改變什麼吧！
一萬小時規則( The10,000hour rule）
在Malcolm Gladwell的書《異數：超凡與平凡的界線在哪裡？（Outliers : The Story of Success）》當中提到想要在不同領域之中成功，其中一個關鍵在於一萬小時的練習。用於Scrum就代表，兩天的課程訓練來學Scrum，一萬小時的練習成為專家，一輩子的時間才成為敏捷大師。
7%，38%，55%規則( The 7%-38%-55% Rule）
此規則來自於Albert Mehrabian。在溝通方面來說，7%跟我們所用的字句有關，38%跟語調有關，55%跟肢體語言有關。如果我們單從字面上來看就認為溝通等於肢體語言，而跟我們用的字句沒太大關係，那麼我們就曲解這個規則的涵義了。敏捷軟體開發宣言中的一個定理指出，「面對面的溝通是開發團隊之間傳遞資訊最有效率和效果最好的方法」。在筆者本身與遠程團隊一同工作的經驗中發現，一個很好的方式便是在每日Scrum匯報（Daily Scrum）時，或者其它時侯，打開網路視訊。能夠看到和聽到對方，可以幫助團隊更感覺像真正的團隊，而不只是一群人在一起工作。
林氏法則（Lin Law）
改變不會隔天就發生，但是如果今天沒有開始，隔天它就不會改變（Change won't happen overnight, but if it doesn't start today, then it won't happen tomorrow.）。
什麼都不改，什麼都不變！（Change nothing and nothing changes！）。
以上所提到的有些是最佳實務（Best practice），有些是諺語，有些則是僅供您參考。沒有一條是絕對的真理。請小心使用，並且您的里程數也會不同。您有最喜歡的規則、法則或者定理嗎？請與我們分享。
最後一件事：保持冷靜，持續敏捷，繼續執行Scrum。明天會更好（Keep calm, be agile, and do Scrum. It's going to be great.）。
文章來源:英文原文刊載於2015 年3 月Scrum Alliance 全球官網上。