How is budgeting done in Scrum?
a. Ideally revised at each Sprint to ensure value is being delivered.
b. Usually every day.
c. Scrum doesn't need a budgeting system.
d. Budgeting is done based on the initial Product Backlog.
敏捷中的預算如何制定?
a.最好在每個衝刺期修訂預算以確保交付的價值
b.通常每天制定預算
c.Scrum不需要制定預算
d.Scrum的預算在最初制定產品Backlog的時候就制定好了
認識Scrum這麼多年,第一次看到Scrum談預算,過往的文章、書籍談的都是Scrum相較於瀑布式專案可以省下幾倍的開發成本、交付更大價值,或大幅縮短產品上市時間,這些比較性或質性的ROI。
也因此,在看到這個問題時,我心裡第一個閃過的是被突襲的慌亂「Scrum Guide有提過預算怎麼編嗎?敏捷從來沒在談預算啊?」,第二念頭卻是「Scrum.org開始面對現實了嗎?蠻棒的」
Scrum的誕生初衷是改善開發的速度與靈活性,一開始就是聚焦於既有流程問題如何被解決,沒有談到預算怎麼編列也是合情合理。而最有名的美國FBI哨兵專案更是在傑夫.薩瑟蘭(Jeff Sutherland)接手時,就已經被限制在既有預算剩餘的2000萬美元及12個月的限期,傑夫.薩瑟蘭當時的唯一關注:全力以赴讓帶領團隊採用Scrum讓哨兵專案起死回生。
雖然如此,但我們還是可以從《Scrum : 用一半的時間做兩倍的事》的內容,以及Brad AI幫忙找到的兩篇文章《The FBI's Sentinel Project: A Case Study in Agile Transformation》及《Scrum in the FBI: A Cost-Saving Success Story》,找出一些與敏捷專案預算有關的描述。
首先,專案不管用什麼手法都需要編列預算,也會有負責審預算與檢驗實際花費的人。監察長在2010年秋季報告描述:「…專案可利用『哨兵』既有預算中剩餘的2,000萬美元完成,所需的時間是在採用此新方法後的12個月內。」
雖然敏捷強調團隊的自組織(self-organization)性,PO要把對客戶、利害關係人有價值的需求放入產品backlog,敏捷團隊需要優先考量在每個Sprint放入及交付有價值的產品增量,PO要負責把敏捷團隊完成的交付項目的價值最大化…但這些都並不代表敏捷團隊的任何決策可以當成「吃到飽自助餐」的資源無限錯誤前提。
資源有限是自然法則般的存在,正因為資源有限,所以才會需要改善開發的速度與靈活性,這是Scrum的誕生初衷,也是整個框架的基石。
既然市場趨勢不斷改變,敏捷強調的又是因應變化即時、彈性的調整,產品backlog是滾動式的、Sprint目標過時的話可以終止、Sprint期間,若有任何新發現,都可以動態調整Sprint backlog的內容,那麼不用特別強調也可以知道預算當然也是跟著變動。
回到這個問題的4個選項,就可以先刪去c、d兩個選項了,我們需要思考的就是檢視預算與調整預算的最佳頻率是多久進行一次?
每個Sprint在規劃計畫的時候,就會由PO提出Sprint目標,那當然最佳的時間點就是在這個會議上一併討論預算,以便讓整個團隊評估投入的時間成本、每個需求要做到什麼程度。
資源有限的自然法則下,當然是有多少錢做多少事、創造多少價值,與敏捷精神不謀而合的精實創業(Learn startup)強調快速交付快速回饋、快速失敗、快速調整,更說明當交付的產品產生實際價值之後,自然會帶動更多的成本投入。這才是更健康、完整又務實的敏捷開發。