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 minimizes 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, prudent management of Epic investments, and dynamic budget adjustments.

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

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

To resolve this, SAFe provides strategies for Lean Budgeting, directly addressing this challenge without the overhead of traditional project-based funding and cost accounting. In this model, 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 a known and approved investment spend. This is the basic principle of fiduciary governance for the development and deployment of IT, software, and hardware, as well as the products, services, and solutions within a SAFe portfolio. As described in Enterprise, each portfolio—and thereby, all portfolios—operates within a budget that results from the strategic planning process illustrated in Figure 1.

Figure 1. Budgeting overview

This is the traditional method, and it’s still relevant in governing investment spending for a SAFe solution portfolio.

After that, however, the Lean enterprise operates far differently, which is the focus of this article. SAFe recommends a dramatically different approach to budgeting, one that reduces the overhead and costs associated with traditional cost accounting, while empowering decentralized 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 shift provides effective fiduciary control over all investment spending, with far less overhead and friction—but much higher throughput, 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
  3. Provide continuous objective evidence of fitness for purpose
  4. Approve epic-level initiatives
  5. Exercise fiscal governance with dynamic budgeting

Each of these is discussed in the sections below.

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 project spending or people (the primary cost element) to the new effort. This creates a number of problems:

  • The project budget process is slow and complicated. It requires many individual budgets (one per cost center) to create 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.
  • Personnel are assigned on a temporary basis. The organization assumes people will come back into the cost center for future assignment. But if they don’t, other planned projects will suffer.
  • The model drives cost center managers to make sure everyone is fully allocated. However, running product development at 100 percent utilization is an economic disaster [2]. The result is high variability to plan.
  • 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.

Project-Based Constraints Thwart Adaptability, Impede Positive Economic Outcomes

Once the project is initiated, the challenges continue. The actual needs of the business, and the project-specific fact patterns, 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. Overhead kicks in. Economics suffer. 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 large degree of technical uncertainty, development is extremely difficult to estimate. And everyone knows that most things take longer than planned. Moreover, even when things go really well, stakeholders may want more of a specific feature. That takes longer, too. Again, project-based funding hampers forward progress, culture, and transparency, as Figure 5 illustrates.

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

When a schedule overruns for any reason, it’s necessary to analyze the variances, re-budget, and re-plan. Resources are scrambled. Personnel are 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 budget impact. But the real casualties are transparency, productivity, and morale.

Beyond Project Cost Accounting with SAFe

Clearly, traditional cost accounting undermines the goal of faster delivery and better economic outcomes. But, as we indicated, there’s a solution, each element of which is described in the sections below.

Fund Value Streams, Not Projects

The first step is to increase empowerment and decrease overhead by moving the day-to-day spend decisions (and associated resource decisions) to the people closer to the solution. We do this by allocating Lean budgets to each value stream, as Figure 6 illustrates.

Figure 6. Operating budgets (allocated spend, personnel, and other resources) are defined for each Value Stream

This is a major step, and it delivers many 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 the Agile Release Trains (ARTs) that realize them are long-lived, the people involved work together for an extended period of time, increasing esprit de corps, knowledge, competency, and productivity.
  • Value streams provide resource pooling. So when things change, people in the value stream can flex to the current context. They can also move from team to team, and potentially ART to ART, without requiring permissions above the value stream/ART level.
  • 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 get worked on. And when a feature takes longer than planned, there’s no impact on the budget, and personnel decisions are a local—not budget or program—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.

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 projects were created to begin with. SAFe provides for this—not with projects, but through the empowerment and responsibilities of Solution and Product Management. And to provide visibility to everyone, all upcoming work is conducted, contained, and prioritized in the Solution and Program Backlogs, as illustrated in Figure 8.

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

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

Provide Objective Evidence of Fitness for Purpose

Principle #5 – Base milestones on objective evaluation of working systems provides 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.

Approve Epic Level Initiatives

While the value stream is funded in the aggregate, 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; costs may run into many millions of dollars. That is why they all require vetting through the system and a Lean business case, whether they arise at the portfolio, Large Solution, or Program Level, as Figure 9 illustrates.

Figure 9. Epics require approval

Unanticipated portfolio epics may be funded by a budgetary reserve, by reallocation of personnel or budgets from another value stream, or simply the awareness that a large spend is going to consume a big portion of an existing value stream budget. In any case, epics are large enough to require analysis, as well as strategic-level and financial-level decision-making. That—along with the Lean business case—is what makes an epic an epic.

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. In order to respond to change, however, funding will vary over time based on business dynamics, 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: 20 September, 2017