1. 本質
    1. 團隊明瞭市場目標與價值取向
    2. 聚焦問題本身，避免資源耗損
    3. 重要緊急﹑重要不緊急之間的取捨
  2. 參與角色 (Scrum Team)
    1. PO (Product Owner)
      1. 決定做什麼（What）
      2. 決定產品規劃，負責產品成敗
      3. 平衡市場與利害關係人
    2. DevTeam (Development Team)
      1. 決定如何做（How）
      2. 開發產品所需的功能
      3. 自我管理﹑持續迭代，各組人數控制在 7± 2 人
    3. SM (Scrum Master)
      1. 協調時程，角色如 PM
  3. Scrum Defination
    1. Item (Story)
      1. PO 所定義的產品產出
      2. 以 3-5 個為基準
    2. Task
      1. DevTeam 針對 Item 列出所需完成的工作內容
      2. 如 Item: 成就系統，則 Task 為各項完成該系統的開發項目
    3. Product Backlog（產品待辦清單）
      1. PO 整理產品路線圖，以 Item 為單位，由上而下
    4. Sprint Backlog（衝刺待辦清單）
      1. DevTeam 向 PO 承諾會完成的 Item
      2. 以 Task 為單位
    5. Potentially Shippable Product Increment （潛在可交付產品增量）
      1. DevTeam 的產出
      2. 已開發完成﹑隨時可上線的開發功能
    6. Burndown Chart（竣工圖/燃盡圖）
      1. 剩餘多少 Sprint Backlog 才能完成
      2. 以 Task 為單位
  4. Scrum Active
    1. Sprint（衝刺）
      1. DevTeam 決定開發哪些 Item
      2. 以 2-3 週為一個時間區塊
    2. Daily Sprint（每日站立會議）
      1. 每天 10-15 分鐘
      2. 目的於同步開發進度
    3. Sprint Planning（衝刺會議）
      1. 討論該 Sprint 可由哪個 DevTeam
      2. PO 決定 Item 順序
      3. DevTeam 決定選多少 Item 放入 Sprint 裡頭
    4. Product Backlog Refinement (PBR) （產品待辦清單精煉會議）
      1. PO 與 Scrum Team 討論近期將開始的 Item
      2. 從商業和使用者角度切入，盡可能不觸及技術細節
    5. Sprint Review（衝刺檢視會議）
      1. 一個 Sprint 結束時，針對產品自身的會議
      2. PO 邀請利害關係人給出產品建議，單純以軟體使用上的回饋
    6. Sprint Retrospective / Sprint Retro （衝刺回顧會議）
      1. 每個 Sprint Team 參與成員（DevTeam 與 PO），討論該 Sprint 工作的改善
      2. 訂定下個 Sprint 改善事項，讓 Sprint 推行更流暢
  5. Scrum Timeline Per Sprint
    1. Sprint 前
      1. 1. Product Backlog Refinement（產品待辦清單精煉會議）
        1. 使 Team 瞭解價值定義的 WHY
      2. 2. Sprint Planning（衝刺會議）
    2. Sprint 中
      1. Daily Sprint（每日站立會議）
    3. Sprint 後
      1. Sprint Review（衝刺檢視會議）
      2. Sprint Retro（衝刺回顧會議）
  6. SCRUM 導致失敗評分清單
    1. 評分內容
      1. 1. 沒有溝通產品的願景和策略
      2. 2. 產品藍圖和發佈日期在一年前就由 CTO 規劃好了
      3. 3. 組織內沒有人跟顧客對談
      4. 4. CTO 和利害關係人堅持所有的改動都要經由他們批准
      5. 5. 因為保密資安等理由，禁止使用實體的看板或告示（訊息不透通）
      6. 6. 利害關係人直接跟CTO對談，跳過 PO
      7. 7. 由利害關係人來決定交付產品增量，而不是 PO
      8. 8. 專案/產品只有在完成時才交付，而不是增量式的交付
      9. 9. 利害關係人無法直接跟開發團隊對談
      10. 10. Product Backlog 是由一個產品委員會決定的
      11. 11. 就算對功能的價值有所懷疑，但還是硬幹
      12. 12. 業務為了成交，答應客戶增加目前不存在的功能，而 PO 不知情
      13. 13. 就算是不重要的問題，也有固定的進度表和期限
      14. 14. 負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定
      15. 15. 利害關係人使用需求文件來和產品與工程部門溝通
      16. 16. PO 大部分的時間都在撰寫和管理使用者故事 (User Stories)
      17. 17. 在 Sprint 開始後不久 Sprint Backlog 就變了
      18. 18. 專門成立一個開發團隊來修 Bugs 和處理小的需求
      19. 19. 利害關係人沒有參加過 Scrum 活動（如 Sprint Planning 和 Sprint Review）
      20. 20. 主要是用『速率（Velocity）符合當初的承諾』來當指標評估 Scrum 是否成功
      21. 21. 開發人員沒有參與創造使用者故事
      22. 22. 同時處理的專案數量和工作改變了開發團隊的人數跟組成方式
      23. 23. 在 Daily Stand up 中團隊成員只對 SM 報告
      24. 24. 定期舉行自省會議（Retrospectives），但沒有改變隨之發生
      25. 25. 開發團隊並不是跨功能 (Cross Functional)，而要靠其他團隊或部門才能完成工作
    2. 評分結果
      1. 平均0 – 2個：太神奇了，可以跟作者聯絡你們是怎麼辦到的嗎？
      2. 平均3 – 5個：事情看起來是朝對的方向發展
      3. 平均6 – 8個：有蠻多可改善的空間
      4. 平均9 – 14個：如果你們不是剛剛開始跑敏捷，可以考慮換個實行方式
      5. 平均15 – 20個：試試重新開始導入敏捷吧，目前的安排在你們組織沒用
      6. 平均21 – 25個：要嘛是你們還沒開始跑敏捷，要嘛是在傳統的專案方式外包裝了敏捷的糖衣，良心建議：這沒用
      7. 項次越多失敗越大