傳統專案管理的方法，著重在專案啟始的規劃階段，希望能藉由完整詳盡的需求訪談和系統分析設計，透過各式的流程圖和需求確認文件來同步彼此的認知，降低開發期的規格變更風險。但在軟體開發專案時，經常是不斷變更規格，需求一變再變，以雲端貿易系統的軟體開發專案為例，使用者往往無法清楚地表達自己的需求，因為貿易系統功能牽涉到領域Know-how，使用者又不具備軟體設計的專業知識，所以往往會在需求訪談時產生「口是心非」、「雞同鴨講」的情形，導致系統功能開發完成後才發現功能不符需要打掉重做，如此的耗時費力常造成專案範疇、時程和資源暴增的失敗。
因應以上的情境，可以導入 Scrum 專案管理方法以提升專案成功率，由於大部分的軟體開發專案都會有交付時間的限制，而且專案啟始期總是難以明確界定需求，所以 Scrum 的管理重點就放在專案時程內的需求確認及變更管理上，頻繁地以部分雛型向客戶確認需求，每次展示時讓客戶提供一些反饋，就能知道開發方向是否需要修正，藉此逐步完成專案的目標。
在 Scrum 專案管理的團隊中，可分為一種輔助角色和三種主要角色：
先介紹輔助角色，也就是利害關係人，通常是客戶，負責說明產品需求，或是提供團隊工作的環境和資源。而第一種主要角色是 Scrum 團隊的負責人(Product Owner)，負責釐清客戶對於產品的需求，將需求拆解成工作項目並以重要性排序，也負責確認整個專案的開發進度。第二種主要角色是 Scrum 團隊的促進者(Scrum Master)，幫助團隊移除工作週期中所遇到的障礙，使團隊可以依循著 Scrum 的精神進行開發，類似 Scrum 團隊的秘書，負責流程改善、解決問題、整合團隊。第三種主要角色是 Scrum 團隊的開發人員(Team Member)，建議成員具有各式技能，如資料庫設計、UI設計、美術設計等，負責專案的實際開發工作。
在 Scrum 的專案管理工作中，會有三種紀錄及三種會議：
首先是「故事」(Story)，也就是客戶提供的需求紀錄，包含需求的情境，從專案開始到結束需要執行的所有工作，都會以故事描述的方式說明呈現；其次是「產品需求」(Product Backlog)，將故事中的需求進行拆解後，可以分成很多個工作項目，並註記其重要性和必須完工的時間，以作為整個專案的產品需求紀錄；最後一種紀錄是「工作清單」(Sprint Backlog)，呈現每個工作週期所需要完成的工作項目。
「工作規劃會議」(Sprint Planning Meeting)，類似Kick-off Meeting，在每個工作週期啟動之前召開，讓所有團隊成員一起進行討論工作分派，安排這個工作週期所要完成的工作項目。「工作日報」(Daily Scrum Meeting)，每天都簡短地召開，報告當日完成的工作項目、明日預計的工作項目、是否出現需要協助排除的障礙，由促進者進行協調處理。「展示會議」(Sprint Review Meeting)，在每個工作週期完成之後召開，展示這個工作週期所完成的工作項目，讓負責人和客戶可以驗收階段成果是否符合期望，先確認最核心的關鍵工作項目，再考慮調整其他工作項目的重要性，或是直接決定捨棄部份產品需求。
綜上所述，在 Scrum 的工作週期中提供團隊成員更多自主性，也仰賴團隊間更大量的溝通與合作。對客戶而言，透過每次的展示回饋可以更即時地驗證功能是否符合需求，以導正系統開發方向，避免到系統測試期才能看到系統問題，卻已經錯失修正開發方向的時機。簡而言之，導入 Scrum 專案管理方法是為了在時間有限的情況下，將資源投入在最重要的產品需求項目，採用更敏捷的方式進行需求變動管理以提升專案成功率。
相關文章：[議題探討]何謂專案及專案管理？