Skip to content

Funding Agile Work: Fixed Budgets, Flexible Scope, Value First

How to fund agile work without losing accountability, using GAO's Agile Assessment Guide, DORA, the Digital Services Playbook and official framework guidance.

Transform Agile · Last reviewed October 24, 2026 · 6 min read

Funding is where many agile transformations quietly stall. Teams learn to plan in short cycles and change direction based on feedback, but the money still arrives through annual project budgets that assume the scope was known on day one. The result is a constant translation exercise between how work is done and how it is paid for.

There is no single correct funding model, and this guide does not promote one. Instead, it pulls together what neutral and official sources say: the U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506), DORA's transformation guidance, the federal Digital Services Playbook, and how two scaling frameworks, SAFe and Scrum@Scale, describe their own approaches.

The aim is practical: to help finance leaders, portfolio managers and executives fund agile work in a way that keeps both flexibility and accountability.

Why project budgets and agile delivery pull against each other

DORA's guide to transforming your organization observes that the annual budgeting cycle tends to drive organizations toward a project-based model, in which work of all kinds is tied to expensive projects that take a long time to deliver. It recommends breaking work into smaller pieces delivered incrementally, and describes the move from a project paradigm to a product paradigm as a long-term trend.

Scaled Agile's article on Lean Budgets opens with a quotation from Rami Sirkia and Maarit Laanti: "Agile software development and traditional cost accounting don’t match." SAFe's own answer, which it calls Lean Budgets, is defined on the Scaled Agile site as a financial governance approach that funds value streams instead of projects. In SAFe, each portfolio operates within an approved budget. You do not have to adopt SAFe to borrow the underlying question: are you funding temporary projects, or the long-lived teams and products that deliver value?

Fix cost and time, flex the scope

GAO's guide describes the core trade-off clearly. In a waterfall development, requirements are fixed while schedule and cost are variable. In agile development, program cost and schedule are fixed but the requirements are variable for each iteration.

GAO is also realistic about the limits. It notes that government programs generally do not have the autonomy to manage a completely flexible scope. When scope cannot be fully flexible, GAO says it is vital to separate "must have" requirements from "nice to have" ones early, so the must-haves are delivered first. It adds that it may be possible to acquire a minimum viable product with a fixed budget or fixed schedule, while cautioning that cost and schedule overruns may still occur to achieve the overall program scope.

For a funding decision, that means the useful question shifts from "what will we get for this money?" to "what is the most valuable thing we can be confident of getting for this money, and what would we do next if more is approved?"

Fund the highest-value work first

Ordering work by value is not only a product practice. It is a financial safeguard. GAO's guide states that the best practice is to prioritize requirements so that the highest-value work is completed first, "so that if funding ends, the customer will still benefit from the work that has been completed to date." It warns that building every user story regardless of relative value can lead to problems if funding is reduced partway through an iteration, release or program.

For a hypothetical example, imagine a benefits agency that funds a new online application in two-month increments. If the first increments deliver the most-used application path end to end, a budget cut in month six still leaves citizens with a working service. If the first increments build administrative screens and infrastructure for every future feature, the same cut leaves nothing usable.

Keep estimates, but use them differently

Agile funding is not a reason to stop estimating. GAO says the importance of a reliable cost estimate "cannot be emphasized enough," and its guide maps its 12-step cost estimating process onto agile cadences. It describes integrated cost estimating throughout the program, so the program can collect the data needed to estimate what fits within the total budget as it progresses. It also notes that a budget may be fixed for a single iteration, but if requirements are not completed, management may need information to justify additional funds and a change in schedule.

GAO's case studies show the risk of skipping this. In its 2023 review of a Department of Defense personnel vetting system (GAO-23-105670), GAO found the program's cost estimate was not reliable. Program documentation stated that development was based on the funding available, with shortfalls resolved by reprioritizing requirements or delaying activities. GAO's point was that projecting future costs still matters for software programs, because managers generally do not know enough at the start about the exact requirements that will be needed.

Two cautions about the numbers agile teams produce. GAO notes that team velocity can support more accurate cost estimates when teams work at a sustainable pace, but that velocity is team-specific and should not be compared across teams. And GAO describes setting high-level targets or guardrails for schedule and cost from the program vision, with an initial product road map created early to show how far estimates are from those targets.

Revisit funding on a regular cadence

If priorities change every few weeks, funding decisions need a predictable place to change too. The Scrum@Scale Guide describes an Executive MetaScrum, where leaders and stakeholders meet with the Chief Product Owner to "negotiate priorities, alter budgets, or realign teams to maximize the delivery of value." The guide says this happens as often as needed, at least once per Sprint, and that such decisions should not be made at other times during the Sprint.

Whatever structure you use, the principle is the same: a regular, visible forum where funding follows evidence from working results, rather than ad hoc requests that interrupt teams mid-cycle.

GAO's guide also offers an argument for funding stable teams rather than assembling new ones for each project. It says team stability, where members are dedicated and do not move in and out, is important for consistent productivity, and that frequently shifting people can undo learning and reduce a team's ability to meet commitments.

Notes for federal and public-sector leaders

Public-sector budgets add rules that agile approaches must work within. GAO's guide points to Office of Management and Budget guidance that defines adequate incremental development as delivery of new or modified technical functionality to users at least every six months. It also notes that the Federal Information Technology Acquisition Reform Act (FITARA) requires CIOs at covered agencies to certify that certain IT investments are adequately implementing incremental development.

The Digital Services Playbook's play "Structure budgets and contracts to support delivery" includes checklist items stating that the budget includes research, discovery and prototyping activities, and that contracts request frequent deliverables rather than multi-month milestones. Its related play on experienced teams lists a federal budget officer on the internal team or as a partner. Bringing finance into the team early is cheaper than translating for it later.

Key takeaways

  • DORA notes that annual budgeting cycles tend to push work into long, expensive projects; incremental funding supports incremental delivery.
  • GAO describes agile programs as fixing cost and schedule while flexing requirements, but warns that government scope is rarely fully flexible, so separate must-haves early.
  • Ordering work by value protects the investment: if funding stops, users keep what was built.
  • Keep reliable cost estimates and update them with real data; do not compare velocity across teams.
  • Give funding decisions a regular, visible cadence and favor stable, long-lived teams.

Sources

Spotted something out of date? Let us know.

More in Leading Agile Change