How to control costs in agile projects

“Time and materials” sounds to many clients like an open check. The fear is understandable – but it rests on a misunderstanding. An agile project actually has unusually predictable cost: the team costs the same every sprint. What varies isn’t the bill but the content. Here are the controls that keep the budget on track.

The sprint budget: your most important number

An agile team has a known and stable cost per sprint. A team of four costs, at Swedish agency rates, typically SEK 300,000-400,000 per two-week sprint. That means a budget of SEK 1.5 million covers roughly four to five sprints – eight to ten weeks of development.

Already there, the cost is more predictable than most fixed-price projects: you know exactly what each two-week period costs, and you can work out at any time how many sprints remain in the budget. The uncertainty shifts from “what will this cost?” to “what can we get built?” – and you control that question yourself through prioritization.

Burn rate: spot deviations within weeks, not at delivery

Burn rate is the rate of spend against the budget. In a well-run agile project it’s tracked every sprint: amount spent, content delivered, and a forecast for what remains. If the forecast deviates, it shows up within two weeks – while there’s still time to do something about it.

Compare that with a fixed-price project where problems can stay hidden for months and surface as a delay or a change request close to the delivery date. Time and materials with sprint tracking gives you more and earlier checkpoints, not fewer.

The triangle: time, cost, and content

In every project, three variables hang together: time, cost, and content. No model can lock all three – something has to give when reality diverges from the plan. A fixed price locks cost and content and lets quality or the timeline absorb the hit. Agile budget control does the opposite: lock time and cost, let content vary.

That only works with a strictly prioritized backlog. The most important thing gets built first, the second most important next, and so on. If the money runs out sooner than expected, you’ve still received the most valuable parts – not 80 percent of everything, but 100 percent of what mattered most.

Stop criteria and decision points

Flexibility without structure does, in fact, become an open check. The protection lies in agreeing on decision points in advance:

• A decision point every sprint or every third sprint with three possible outcomes: continue as planned, change direction, or stop.
• Short notice period – normally one sprint. You should never be locked into months of commitment you don’t want.
• A demo every sprint. You see a working product, not status reports. What you paid for over the last two weeks should be something you can click through.
• A releasable product at all times. A stop doesn’t mean zero value – what’s been built works and can be deployed.

With those four in place, the maximum bad investment is one sprint, not a whole project.

A worked example: the budget that got to decide

A company sets a budget of SEK 1.2 million for a first product version. The team costs about SEK 300,000 per sprint – four sprints. The backlog is prioritized with the core flow at the top; admin tools and reporting fall below the line. After sprint three, the demo shows the core flow working with real users. At the decision point, the client chooses to spend the last sprint on polish and launch instead of the next feature. Result: a launched product, budget held to the krona, and the below-the-line features only get built if users actually miss them.

A fixed-price contract would have delivered everything in the spec – including what turned out to be unnecessary – and priced the risk accordingly.

Common mistakes that make agile budgets run away

• No prioritized backlog. When everything is equally important, things get built in the wrong order and the budget runs out midway.
• An absent client. Without a product owner participating every sprint, decisions get made by the wrong person, or not at all.
• Scope changes without trade-offs. New items are welcome – but something else should then come out.
• No defined total budget. A sprint budget without a cap is sailing without a harbor. Set an overall ceiling even when it’s preliminary.

At Weapp we work in this model on most development engagements, precisely because it gives the client control every sprint instead of a surprise at the end. Want to see what a sprint budget would look like for your project? Get in touch.