這本書包含了三部分：敏捷、Scrum、常見工具補充。
敏捷力
除了簡單說明敏捷的歷史之外，也針對了敏捷宣言的4大價值觀（4 Value）與背後的12項原則(12 Principles)作了還算清楚的說明。
Scrum
描述了 Scrum 的歷史，也針對 Scrum 的角色、產出、事件 有一定程度的描述，很容易理解。
常見工具補充
說明了在敏捷與Scrum 世界裡，常見到的名詞或工具的補充，包含了 Release Planning、Personas、Story Mapping、Paper Prototyping、Refactoring、TDD、Pair Programming。
適合閱讀對象：
對於想了解敏捷/Scrum 的朋友，這本書是一本很容易閱讀又輕巧的小書，很適合當作第一本的入門磚。
若對於敏捷 / Scrum 已經有一定程度的了解，可以不用再讀這本書了，我相信這些你應該都知道了。
敏捷與Scrum軟體開發速成(暢銷回饋版)
# 作者： Chris Sims, Hillary Louise Johnson
# 譯者： 徐毅
# 出版社：博碩
# 出版日期：2015/09/20
# ISBN：9789864340538
英文原書：The Elements of Scrum
===== 以下節錄書籍的重點 ======
迭代式方法
瀑布開發必須先完成目前步驟之後，才能繼續邁向下一步驟。而敏捷團隊的方式事先作一點點需求收集、一點點設計、變寫程式和測試，而且交付一點點價值給客戶。接著團隊在重複此過程，週而復始。同時從工作進度過程中不斷改善、調整流程，一直到專案完成為止。
Scrum Master
一個高產出和更為自我管理的團隊，可能已經不在需要 Scrum Master 來主持 Scrum 會議。稱職的 Scrum Master 會退居幕後並鼓勵他們放手去做。事實上，稱職的 Scrum Master 會不斷的調整自己的風格去適應團隊的需要。Scrum 團隊新建立時，Scrum Master 可能得多教育多指引，隨著團隊技能的提升和對 Scrum 理解的增進，Scrum Master 也在調整方式，轉而扮演共鳴版和案需(on-demand)諫言者的角色，但並不代作決定，而是交由團隊自行決策。
Product Backlog refinement
不論 Sprint 有多長，推薦每星期開一次，每次一小時。
為什麼要打斷流程，不在 Sprint 要結束時在開？
一、refinement 屬於事前型工作，在週期中要趁早完成，以便有充足的前置時間，讓產品負責人可以在他們的計畫和優先順序排序工作中用上這些估算。
二、在 Sprint 長度超過一週的情況下，一小時的會議多開幾次，效果會比一次開幾小時更好，有些人曾經參加過長達四小時的估算會議後，證實是一種痛苦又徒勞無功。
三、你應該不想將 Sprint 的結尾弄的跟馬拉松會議一樣長。
DoD 應該包括
- Code Review
- Design Review
- 重構
- 性能測試
- 通過單元測試
- 更多內容
Scrum 是羽量級框架。他並不告訴你如何規劃發布，或開發產品原型，或編寫及測試程式碼。Scrum 把『HOW』留給團隊決定，這也正是我們喜愛他的原因之一。
敏捷與Scrum軟體開發速成(暢銷回饋版)
# 作者： Chris Sims, Hillary Louise Johnson
# 譯者： 徐毅
# 出版社：博碩
# 出版日期：2015/09/20
# ISBN：9789864340538
英文原書：The Elements of Scrum