Så styr du kostnaden i agila projekt

“Löpande räkning” låter för många beställare som en öppen check. Rädslan är begriplig – men den bygger på ett missförstånd. Ett agilt projekt har i själva verket ovanligt förutsägbar kostnad: teamet kostar lika mycket varje sprint. Det som varierar är inte notan utan innehållet. Här är styrmedlen som gör att budgeten håller.

Sprintbudgeten: din viktigaste siffra

Ett agilt team har en känd och stabil kostnad per sprint. Ett team på fyra personer kostar med svenska byråpriser typiskt 300 000–400 000 kr per tvåveckorssprint. Det betyder att en budget på 1,5 Mkr räcker till ungefär fyra till fem sprintar – åtta till tio veckors utveckling.

Redan där är kostnaden mer förutsägbar än de flesta fastprisprojekt: du vet exakt vad varje tvåveckorsperiod kostar, och du kan när som helst räkna ut hur många sprintar som återstår av budgeten. Osäkerheten flyttar från “vad kommer det att kosta?” till “vad hinner vi bygga?” – och den frågan styr du själv genom prioritering.

Burn rate: se avvikelser inom veckor, inte vid leverans

Burn rate är förbrukningstakten mot budgeten. I ett välskött agilt projekt följs den upp varje sprint: förbrukat belopp, levererat innehåll och prognos för återstoden. Avviker prognosen syns det inom två veckor – medan det fortfarande går att göra något åt saken.

Jämför med ett fastprisprojekt där problem kan ligga dolda i månader och dyka upp som en försening eller ett ändringskrav nära leveransdatumet. Löpande räkning med sprintuppföljning ger dig fler och tidigare kontrollpunkter, inte färre.

Triangeln: tid, kostnad och innehåll

I varje projekt hänger tre storheter ihop: tid, kostnad och innehåll. Ingen modell kan låsa alla tre – något måste få ge vika när verkligheten avviker från planen. Fastpris låser kostnad och innehåll och låter kvaliteten eller tidplanen ta smällen. Agil budgetstyrning gör tvärtom: lås tid och kostnad, låt innehållet variera.

Det fungerar bara med en strikt prioriterad backlog. Det viktigaste byggs först, det näst viktigaste sen, och så vidare. Om pengarna tar slut tidigare än tänkt har du ändå fått de mest värdefulla delarna – inte 80 procent av allt, utan 100 procent av det viktigaste.

Stoppkriterier och beslutspunkter

Flexibilitet utan struktur blir mycket riktigt en öppen check. Skyddet ligger i att avtala om beslutspunkter i förväg:

• Beslutspunkt varje eller var tredje sprint med tre möjliga utfall: fortsätt enligt plan, ändra riktning eller stoppa.
• Kort uppsägningstid – normalt en sprint. Du ska aldrig sitta fast i månader av åtagande du inte vill ha.
• Demo varje sprint. Du ser fungerande produkt, inte statusrapporter. Det du betalade för de senaste två veckorna ska gå att klicka på.
• Releasebar produkt löpande. Ett stopp betyder inte noll värde – det som är byggt fungerar och kan driftsättas.

Med de fyra på plats är den maximala felinvesteringen en sprint, inte ett projekt.

Räkneexempel: budgeten som fick bestämma

Ett företag sätter budgeten 1,2 Mkr för en första produktversion. Teamet kostar cirka 300 000 kr per sprint – fyra sprintar. Backloggen prioriteras med kärnflödet överst; adminverktyg och statistik hamnar under strecket. Efter sprint tre visar demon att kärnflödet fungerar med riktiga användare. Vid beslutspunkten väljer beställaren att lägga sista sprinten på polering och lansering i stället för nästa funktion. Resultatet: lanserad produkt, budget hållen på kronan, och funktionerna under strecket byggs bara om användarna faktiskt saknar dem.

Ett fastprisavtal hade levererat allt i specen – inklusive det som visade sig onödigt – och prissatt risken därefter.

Vanliga misstag som får agila budgetar att skena

• Ingen prioriterad backlog. När allt är lika viktigt byggs saker i fel ordning och budgeten tar slut mitt i.
• Frånvarande beställare. Utan produktägare som deltar varje sprint fattas beslut av fel person eller inte alls.
• Scope-ändringar utan byteshandel. Nytt får gärna komma in – men något annat ska då lyftas ut.
• Ingen definierad totalbudget. Sprintbudget utan tak är att segla utan hamn. Sätt en totalram även när den är preliminär.

Vi på Weapp arbetar i den här modellen i de flesta utvecklingsuppdrag, just för att den ger beställaren kontroll varje sprint i stället för en överraskning på slutet. Vill du se hur en sprintbudget skulle se ut för ditt projekt? Hör av dig.