What it means
The traditional alternative, usually called waterfall, defines everything up front and then moves through design, build and testing in sequence. That works when requirements genuinely are known in advance, and it fails badly when they are not, because the first honest feedback arrives only after the money has been spent.
Agile inverts this by making feedback the earliest input rather than the last. The mechanics are consistent across most variants.
Work is broken into small items, sized in relative units rather than hours, and pulled from a prioritised list called a backlog into fixed length cycles known as sprints, typically one to four weeks. At the end of each cycle the team demonstrates working output and the priority list is reordered based on what was learned.
For anyone holding a budget, the important shift is what gets fixed and what stays flexible. In a waterfall contract the scope is fixed and the cost moves; in an agile arrangement the time and the team cost are fixed and the scope moves.
That makes agile forecasting a matter of predicting how much a team can deliver rather than exactly which features will exist by a date. This creates a genuine accounting question that finance teams have to work through.
Development costs can sometimes be capitalised as an intangible asset once a project reaches technical feasibility, and agile blurs the boundary between research and development because building and learning happen simultaneously. Most finance functions resolve this by tying capitalisation to specific sprint outputs rather than to project phases.
The most common failure is adopting the ceremonies without the substance. A team that holds daily stand ups and calls its two week blocks sprints, but still works to a fixed scope agreed a year earlier, has taken on the overhead of agile without the benefit.
The point is the willingness to change direction based on evidence, and no meeting cadence substitutes for that.
In practice
Real-world examples.
Example
An insurance company rebuilding its claims portal releases a working version handling one claim type after six weeks, rather than waiting eighteen months for the full system. Early users identify a document upload problem that would have been baked into every claim type had the team built everything first.
Example
A consumer goods marketing team adopts two week cycles for campaign development, testing three creative concepts with small paid audiences before committing the main budget. Two concepts underperform and are dropped, and the third receives the spend that would otherwise have been split evenly.
Example
A hardware manufacturer tries to run its firmware team on sprints while the physical product remains on a fixed launch date with tooling ordered a year ahead. The team keeps the cadence for planning and visibility but accepts that scope flexibility is limited, which is a common hybrid in practice.
Think of it
“Agile is working in short cycles with frequent adjustments-flexible, iterative execution.
Formula
Calculation
Average velocity = total story points completed / number of sprints, and forecast sprints remaining = remaining backlog points / average velocity
A product team runs two week sprints and completes 34, 41, 39 and 46 story points across its first four sprints. Total points delivered = 34 + 41 + 39 + 46 = 160, so average velocity = 160 / 4 = 40 points per sprint.
The remaining backlog for the release is estimated at 480 points. Forecast sprints remaining = 480 / 40 = 12 sprints, and at two weeks each that is 12 x 2 = 24 weeks, or roughly five and a half months. If the team costs $80,000 per sprint in fully loaded salaries, the remaining release carries an expected cost of 12 x $80,000 = $960,000, which is the number a finance director can actually plan against.Case study
Seen in the real world.
This is an illustrative and clearly fictional scenario. Fernbank Learning, an invented company selling training software to hospitals, had spent eleven months and $2,300,000 building a course authoring tool specified in a 180 page requirements document signed off at the outset. When the first version reached customers, the feature customers used most was a simple progress dashboard that had been listed as low priority, while an elaborate assessment engine that consumed a third of the budget went almost untouched.
The fictional leadership team restructured the following year around two week sprints with a customer advisory group reviewing output at the end of each one. Velocity settled at around 40 story points a sprint after four sprints, which gave the finance function a usable planning number for the first time. Scope was reordered eleven times over the next six months, and three substantial features were dropped entirely before any significant money was spent on them.
The measurable outcome in this invented example was not that the team built faster; velocity was broadly comparable. It was that roughly $700,000 of work that customers did not want was never built, which the chief financial officer treated as the real return on the change.
Watch out
Common mistakes.
- Treating agile as an excuse for having no plan, when the method requires a prioritised backlog, a clear goal for each sprint and disciplined review.
- Comparing velocity between different teams, when story points are a relative measure calibrated inside one team and mean nothing across teams.
- Keeping a fixed scope and a fixed date while adopting sprints, which delivers all of the overhead and none of the flexibility.
Questions
People also ask.
Does agile mean there is no budget or deadline?
No, both are usually fixed, and it is the scope delivered within them that flexes, which is why velocity forecasting matters so much.
Can agile work outside software?
Yes, it is widely used for marketing, product design and internal process change, though it fits poorly where regulatory approval or physical tooling locks the sequence.
How does agile affect capitalising development costs?
Finance teams generally tie capitalisation to specific deliverable outputs from sprints once technical feasibility is established, rather than to the traditional project phases, and the policy needs agreeing with the auditor in advance.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%