Agile software development and traditional cost accounting don’t match.

—Rami Sirkia and Maarit Laanti


Lean Budgets

Lean Budgets is a set of practices that minimize overhead by funding and empowering Value Streams rather than projects while maintaining financial and fitness-for-use governance. This is achieved through objective evaluation of working systems, active management of Epic investments, and dynamic budget adjustments.

Each SAFe Portfolio exists for a purpose: to realize some set of Solutions that enable the business strategy. Each portfolio must work within an approved budget, as the operating costs for solution development are a primary factor in economic success.

Many traditional organizations quickly realize, however, that the drive for business agility through Lean-Agile development conflicts with current methods of budgeting and project cost management and accounting. The result may be that the move to Lean-Agile development—and realizing the potential business benefits—is compromised. Or, worse, it’s simply unachievable.

SAFe provides strategies for Lean budgeting that eliminates the overhead of traditional project-based funding and cost accounting. In this model, Lean Portfolio Management (LPM) fiduciaries have control of spending, yet programs are empowered for rapid decision-making and flexible value delivery. This way, enterprises can have the best of both worlds: a development process that is far more responsive to market needs, along with professional and accountable management of technology spending.


Every SAFe portfolio operates within an approved budget, which is a fundamental principle of financial governance for the development and deployment of products, services, and IT business Solutions  (software, hardware, firmware) within a SAFe portfolio. As described in Enterprise, the budget for each portfolio results from a strategic planning process illustrated in Figure 1.

Figure 1. Budgeting overview

SAFe recommends a dramatically different approach to budgeting, one that reduces the overhead and costs associated with traditional cost accounting, while empowering Principle #9, Decentralize Decision-Making.

With this new way of working, portfolio-level personnel no longer plan the work for others, nor do they track the cost of the work at the project level. Instead, the Lean enterprise moves to a new paradigm: ‘Lean budgeting, beyond project cost accounting.’ This approach provides effective financial control over all investments with far less overhead and friction and supports a much higher throughput of development work, as summarized in Figure 2.

Figure 2. Empowerment and governance with Lean-Agile budgeting

Figure 2 illustrates the five major steps to this future state:

  1. Fund value streams, not projects
  2. Empower value stream content authority (e.g., Solution Management)
  3. Provide continuous objective evidence of fitness for purpose
  4. Approve epic-level initiatives
  5. Exercise fiscal governance with dynamic budgeting

Each of these steps is discussed in the next sections.

The Problem of Traditional Project Cost Accounting

Before we do so, however, it’s important to understand the problems caused by the traditional project approach to technology funding:

Cost-Center Budgeting Creates Multiple Challenges

Figure 3 represents the budgeting process of most enterprises before they move to Lean-Agile development.

Figure 3. Traditional project-based cost budgeting and cost accounting model

The enterprise is organized into cost centers. Each cost center must contribute to project spending or people (the primary cost element) to the new effort. This creates some problems:

  • The project budget process is slow and complicated. It requires many individual cost center budgets to fund the project.
  • It drives teams to make fine-grained decisions far too early in the ‘cone of uncertainty.’ If they can’t identify all the tasks, how can they reasonably estimate how many people are needed, and for how long? Their hand is forced.
  • People are assigned on a temporary basis. After the project is complete, people return to their organizational silo for future assignment within their cost center. And if they don’t, other planned projects will suffer.
  • The model drives cost center managers to make sure everyone is fully allocated to one or more projects. However, running product development at 100 percent utilization is an economic disaster [2], resulting in high variability between forecasted and actual, time and costs.
  • The model prevents individuals and teams from working together for longer than the duration of a single project. This hinders learning, team performance, and employee engagement. And collocation is out of the question. What happens if the project takes longer than planned—which it often does—many people will have moved on to other projects, and further delays will occur.

Project-Based Constraints Impede Adaptability and Positive Economic Outcomes

Once the project is initiated, the challenges continue. The needs of the business and the project change quickly. However, because the budgets and personnel are fixed for the project term, the projects can’t flex to the changing priorities, as Figure 4 illustrates.

Figure 4. Project funding inhibits the ability to react to change

The result is an organization is unable to adapt to changing business needs without the overhead of re-budgeting and reallocating personnel. The Cost of Delay (CoD)—the cost of not doing the thing, you should be doing—increases.

Delays Happen. Things Get Even Uglier

But we are not done. Product development cannot innovate without takings risks [2]. Because it contains a high degree of technical uncertainty, it’s challenging to estimate product development. And everyone knows that most things take longer than planned. Moreover, even when things go well, stakeholders may want more of a specific feature. That requires approval from a change control board, which adds further delay. Again, project-based funding hinders progress, culture change, and transparency, as Figure 5 illustrates.

Figure 5. When overruns happen, project accounting and re-budgeting increase CoD and negatively impact culture

When a schedule overruns for any reason, it’s necessary to analyze the variances, re-plan and adjust budgets. Resources are scrambled. Personnel is reassigned. As a result, other projects are negatively impacted. Now, the ‘blame game’ sets in, pitting project managers against each other and financial analysts against the teams. Any project overrun has a budget impact. But the real casualties are transparency, productivity, and morale.

Beyond Project Cost Accounting with SAFe

Traditional cost accounting undermines the goal of faster delivery and better economic outcomes. But, as we indicated, there are five major steps to a better future state:

1. Fund Value Streams, Not Projects

The first step is to increase empowerment and decrease overhead by moving the day-to-day spending and resource decisions to the people closest to the solution domain. Each value stream is assigned a budget as Figure 6 illustrates.

Figure 6. Operating budgets (people and other resources) are defined for each value stream

This is a significant step, and it delivers several benefits to the Lean enterprise:

  • Value stream stakeholders, including the Solution Train Engineer (STE) and Lean Portfolio Management (LPM), are empowered to allocate the budget to the personnel and resources that make sense based on the current backlog and Roadmap.
  • Since value streams and Agile Release Trains (ARTs) are long-lived, people work together for an extended time, increasing engagement, knowledge, competency, and productivity.
  • Self-organizing ARTs and value streams enable moving people from one ARTs and Agile Teams to another, without requiring permission from management above the Program or Large Solution levels.
  • The budget is still controlled. In most cases, the expenses across a Program Increment (PI) are fixed or easy to forecast. So all stakeholders know the anticipated spend for the upcoming period, regardless of what features are implemented. And when a feature takes longer than planned, there’s no impact on the budget, and personnel decisions are a local concern, as Figure 7 illustrates.
Figure 7. The budget for a Program Increment (PI) is fixed. When things take longer than anticipated, resources are not moved, and the budget is not affected.

2. Empower Value Stream Content Authority

Step #1 is a giant leap forward. Budget aside, however, the enterprise still needs assurance that the value streams are building the right things. That’s one of the reasons the project model was created. SAFe provides for this, however, without the overhead of projects, but through the empowerment and responsibilities of Product and Solution Management. And to give visibility to everyone, all upcoming work is conducted, contained, and prioritized in the Program and Solution Backlogs, as illustrated in Figure 8.

Figure 8. Transparent content decision-making authority by Product and Solution Management

Work is pulled from the backlogs based on Weighted Shortest Job First (WSJF) economic prioritization, assuring that there are sound and logical economic reasoning behind these critical decisions and that the right stakeholders are involved.

3. Provide Objective Evidence of Fitness for Purpose

Principle #5 – Base milestones on objective evaluation of working systems provide the next piece of the puzzle. It’s one thing to allocate the budget in value stream–sized chunks. But it’s reasonable for all involved to want fast feedback on how the investment is tracking. Fortunately, SAFe provides regular, cadence-based opportunities to assess progress every PI via the Solution Demo and, if necessary, every two weeks via the System Demo. Participants include such key stakeholders as the Customer, Lean Portfolio Management, Business Owners, and the teams themselves. Any fiduciary can participate for assurance that the right thing is being built in the right way and that it’s meeting the customer’s business needs, one PI at a time.

4. Approve Epic Level Initiatives

While each value streams is funded, there is an exception to that rule. By their very definition, epics are large enough and impactful enough to require additional approval. Often these initiatives affect multiple value streams and ARTs and costs may run into many millions of dollars. That is why all epics need review and LPM approval through the Kanban system and a Lean business case, whether they arise at the portfolio, Program or Large Solution levels, as shown in Figure 9 illustrates.

Figure 9. Epics require approval

Spending on epics may be funded by a portfolio budget reserve or reallocating people or money from one value stream to another, or simply accepting that an epic will consume a significant portion of an existing value stream budget.

In any case, epics are large enough to require analysis, as well as strategic and financial review and decision-making. That, along with the Lean business case is what makes an epic—an epic.

5. Exercise Fiscal Governance with Dynamic Budgeting

Finally, although value streams are largely self-organizing and self-managing, they do not launch or fund themselves. As a result, LPM has the authority to set and adjust the value stream budgets within the portfolio. To respond to change, however, funding will vary based on business needs, as Figure 10 illustrates.

Figure 10. Value Stream budgets are adjusted dynamically over time

Nominally, these budgets can be adjusted twice annually. Less frequently than that, and spending is fixed for too long, limiting agility. More frequently, and the enterprise may seem to be very Agile, but people are standing on shifting sand. That creates too much uncertainty and an inability to commit to any near-term course of action.

Learn More

[1] Special thanks to Rami Sirkia and Maarit Laanti for an original white paper on this topic, which you can find here.

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.




Last update: 13 November 2017