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

—Rami Sirkia and Maarit Laanti

Budgets Abstract

Each SAFe portfolio exists for a purpose, to realize some set of technical Solutions that enable the business strategy. To enable this, each portfolio must execute within an approved operating budget, as the operating costs for solution development are a primary factor in overall economic success. This article describes the basic mechanics for how SAFe portfolio budgets, once established, are administered and governed within a SAFe portfolio.

However, many traditional enterprises quickly ascertain that the drive for business agility via Lean-Agile development is in inherent conflict with current methods of budgeting and project cost accounting. The result may be that the move to Lean-Agile development—and the potential business benefits—are compromised or, worse, simply unachievable.

To address this, SAFe provides strategies for Lean-Agile Budgets that directly address this challenge without the overhead of traditional project funding. With this model, fiduciaries have control of spend, yet programs are empowered for rapid decision-making and flexible value delivery. In 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 the context of a known and approved investment spend. This is the basic fiduciary governance for development and deployment of IT, software and hardware, products, services, Solutions, and any other product or service offerings within a SAFe portfolio. As described in Enterprise, each portfolio, and thereby all portfolios in total, operate within a budget that is an outcome of the strategic planning process, as is illustrated in Figure 1.

Figure 1. Budgeting overview
Figure 1. Budgeting overview

This is the traditional process, and it is still relevant in providing governance over investment spend for the solution portfolio.

Thereafter, however, the Lean enterprise operates far differently, and that is the focus of this article. SAFe recommends a dramatically different approach to budgeting within the portfolio, one that reduces overhead and costs associated with traditional cost accounting and empowers Decentralized Decision-Making.

No longer do portfolio level personnel 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-Agile Budgeting: Beyond Project Cost Accounting. This paradigm provides effective fiduciary control over total investment spend, but with far less overhead and friction and much higher throughput, as summarized in Figure 2 below.

Figure 2. Empowerment and governance with Lean-Agile budgeting
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

But first, in order to embrace a new solution, it’s important to understand the problems caused by the common project approach to technology funding.

Problem #1 – Cost-center budgeting creates multiple challenges

For most enterprises, prior to moving to Lean-Agile development, the budgeting process appears as in Figure 3.

Figure 3. Traditional project-based cost budgeting and cost accounting model
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, including:

  1. The project budget process is slow and complicated; it takes many individual budgets (one per cost center) to create the project budget.
  2. It drives teams to make fine-grained decisions far too early in the cone of uncertainty. Their hand is forced; if they can’t identify all the tasks, how can they estimate how many people are needed, and for how long?
  3. The assignment of personnel is a temporary thing; the organization assumes people will come back into the cost center for future assignment. If they don’t, other planned projects will suffer.
  4. The model drives cost center managers to make sure everyone is fully allocated. However, running product development at 100% utilization is an economic disaster [2]. The result is high variability to plan.
  5. The model prevents individuals and teams from working together for longer than the duration of just the one project. This retards knowledge acquisition, team performance, and employee engagement. And collocation is out of the question.

Problem #2 – Project-based constraints hinder adaptability, impede positive economic outcomes

Once the project is initialed, the challenges continue. The actual needs of the business and the project-specific fact patterns change quickly. However, the projects cannot flex to the changing priorities, because their budgets and personnel are fixed for the project term, as Figure 4 illustrates.

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

The result is that the organization is unable to flex to the changing business needs without the overhead of re-budgeting and reallocating personnel. Overhead kicks in; economics suffer. The Cost of Delay (the cost of not doing the thing you should be doing) increases.

Problem #3 – Delays happen; things get even uglier

But we are not done. Product development cannot innovate without takings risks [2]. By its very nature, development is extremely difficult to estimate because it contains a large degree of technical uncertainty. 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 hinders forward progress, culture, and transparency, as Figure 5 illustrates.

Figure 5. When “overruns” happen, project accounting and re-budgeting increases Cost of Delay, negatively impacts culture
Figure 5. When “overruns” happen, project accounting and re-budgeting increases Cost of Delay and negatively impacts culture

When a schedule overruns for any reason, it is necessary to analyze the variances, re-budget, and replan. Resources are scrambled, and reassignments of personnel occur. Other projects are negatively impacted. The “blame game” sets in, pitting project manager against project manager and financial analysts against the teams. Any project overrun has budget impact. The casualties are transparency, productivity, and morale.

Beyond Project Cost Accounting with SAFe

Clearly, traditional cost accounting is a serious inhibitor to the goal of faster delivery and better economic outcomes. But, as we indicated, a solution presents itself, each element of which is described in the sections below.

1 – 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 those closer to the solution. We do this by allocating 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
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 (VS) stakeholders, including the Value Stream Engineer (VSE) and Program Portfolio Management, are empowered to allocate the budget to whatever personnel and resources make sense based on the current backlog and Roadmap context.
  • Since value streams, and the Agile Release Trains 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 move from team to team, and even from ART to ART, potentially without requiring permissions above the VS/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 is 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 PI is fixed. When things take longer than anticipated, resources are not moved and the budget is NOT affected.
Figure 7. The budget for a 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 step forward. Budget aside, however, the enterprise must still be assured that the value streams are building the right thing. That’s one of the reasons projects were created to begin with. SAFe provides for this—not with projects, but via the empowerment and responsibilities of Solution and Product Management. And to provide visibility to everyone, all upcoming work is made, contained, and prioritized in the solution and Program Backlogs, as is illustrated in Figure 8.

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

Work is pulled from the backlogs based on WSJF economic prioritization, so fiduciaries are assured that there is 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 provides the next piece of the puzzle. It’s one thing to allocate the budget in value stream-sized chunks, but it’s a reasonable expectation that all involved should get fast feedback on how the investment is tracking. Fortunately, SAFe provides regular, cadence-based opportunities to assess progress every program increment, via the Solution Demo and, if necessary, every two weeks via the System Demo. Participants include key stakeholders such as the Customer, Program Portfolio Management, Business Owners, Release Management, and the teams themselves. Any fiduciary can participate in these demos to help provide assurance that the right thing is being built in the right way, and that it is meeting the business needs of the customer, one program increment at a time.

4 – Approve Epic Level Initiatives

While the value stream is funded in the large, there is an exception to that rule. That is, by their very definition, epics are large enough and impactful enough to require additional approval. Often the initiatives impact multiple value streams and ARTs, and costs may run into many millions of dollars. That is why they all require vetting through the system and a lightweight business case, whether they arise at the portfolio, Value Stream, or Program Level, as Figure 9 illustrates.

Figure 9. Epics require approval
Figure 9. Epics require approval

Portfolio epics may be funded by a budgetary reserve, or perhaps by reallocation of personnel or budgets from another value stream. Value stream epics and program epics may arise locally, or they may occur as a result of portfolio level epics. Upon approval, however, they are funded from value streams. In any case, epics are large enough to require analysis and both strategic and financial-level decision-making. That’s what makes an epic an epic.

5 – Exercise Fiscal Governance with Dynamic Budgeting

Finally, while value streams are largely self-organizing and self-managing, they do not cause their own existence, nor fund themselves. To that end, Program Portfolio Management 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
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 a time, 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: 4 April 2016