Michele Sliger指出在敏捷開發(fā)中每日站立會議、迭代計劃會議、發(fā)行計劃會議、項目回顧（retrospective）以及檢討會議都能應付風險。但是，她也提出結構性風險管理方法。步驟包括，
風險確定——每次迭代中整個團隊都進行一次，在結果紀錄在白板或者活頁樣板上。
風險分析——憑主觀判斷、直覺、及經驗作定性分析去判斷風險和潛在損失。敏捷開發(fā)中的短開發(fā)周期及定期檢討使這分析可行而有效。這有別於傳統(tǒng)項目管理中進行定量分析，按破壞程度配以分數(shù)。
風險反應計劃——整個團隊參與探討相關措施及行動以減低威脅。
風險監(jiān)察及控制——于迭代后期監(jiān)察風險及商討控制策略。以信息輻射體（Information Radiator）方式每日監(jiān)察風險。
Ron Jefferies指出風險不是問題， 而是在Scrum Master的觀察清單上的項目，記錄下哪些事情會出問題。他說，風險有不同的形式，例如內容未組裝好、新或不熟悉的技術、團隊分散於不同地域、與其他項 目的依賴等。Scrum團隊可以按價值和風險程度來決定故事的優(yōu)先次序，花足夠的時間在有風險的故事上，正確地確定及減輕風險，風險應該以故事形式加上 Backlog并被處理。
Michael James提到像Scrum的軟件開發(fā)過程在項目周期中早期小心處理風險，提供各種途徑讓風險得以解決，像每日站立會議、迭代檢討等。根據(jù)Micheal，Scrum不需要創(chuàng)建風險紀錄，但是，團隊能定期管理風險。
有其他人指出，Scrum不能應付項目外部的風險，她能處理有關於需求轉變、缺乏溝通、和團隊表現(xiàn)不濟的風險，但是項目外部的風險就需要Scrum以外的技巧來處理。
Paul Hudson在Scrum Development群組亦同意類似想法， 他提出Scrum能處理項目中大部份的風險，但是Scrum不能處理團隊層面所不能處理的風險。他指出一些例子來支持他的觀點，例如顧客缺乏對Scrum 的認識、第三方產品未能如期運作、項目所依賴的外部因素沒有及時出現(xiàn)、團隊系統(tǒng)有數(shù)據(jù)丟失及遭到破壞、顧客有不同的意見聲音、顧客代表有私心并與項目目的 相違等。
另一個社區(qū)內激烈辯論的題目是“誰負責風險管理？”
Michele Sliger認為，整個Scrum團隊負責風險管理以及減低風險。
在Scrum Development群組的討論上，Ron Jeffries指出，以Scrum的術語來說，是產品負責人有責任去管理風險。有些成員同意Ron的說法，因為產品負責人最了解業(yè)務情況，他/她是決定 那些風險需要處理的最佳人選。產品負責人可以從團隊各成員收集訊息但最終責任始終歸於產品負責人。Peter Stevens說，
作為主要項目投資者，減輕風險直接關乎產品負責人的利益。Scrum Master 和團隊應該幫助產品負責人在Backlog作出最佳排列，但是因為產品負責人需直接負責投資回報（ROI），而風險的后果就是成本，所以風險管理就是產品負責人的責任。
群組上其他會眾提到風險管理是團隊的責任，Scrum團隊所有成員需要同心合力管理風險。
由此可見Scrum能否管理風險以及應否明確指定管理風險都存在分歧。大多數(shù)敏捷社區(qū)的人仕都同意Scrum能處理項目有關的風險，但是當風險處於項目外部 就顯露出真空。同樣道理，到底誰負責風險管理亦沒有共識，有意見傾向產品負責人，但有部份則認為整個團隊有責任管理風險。