Introduction

As adoption of agile extends beyond technology, it has begun to clash with traditional resource planning processes and governance. Organizations must fund agile teams continuously, treating them as durable units rather than temporary cost centers. They know they must disconnect funding from the work, and connect it to the team instead. In legacy terms, we could say that the funding for “change” must look and feel like “run”.

This article outlines a blueprint for agile budgeting in enterprise organizations: how to fund durable teams, estimate value-driven work, and govern financial decisions across agile and hybrid portfolios.

What is agile budgeting?

Agile budgeting is the practice of allocating funding to long-lived teams, forecasting effort and cost, and tracking financial progress across agile delivery models.

Start with work hierarchy

Before getting into the mechanics of investment governance, organizations must first have established a portfolio work hierarchy. This is a critical first milestone for agile budgeting in enterprise organizations, and one which most will have completed. The trick is to ensure that the work hierarchy you establish strikes the balance between being sufficiently high level (and abstracted from delivery) to allow a significant future planning horizon, while also ensuring that it is not so far away from delivery that it becomes meaningless.

A clear work hierarchy is essential for agile budgeting because it defines how funding aligns to long-term initiatives while remaining flexible enough to support iterative delivery.

We have found that this work hierarchy (illustrated below) is effective in achieving this.

 

The diagram above illustrates how this should be done. The specific nomenclature that you choose to use is not important, but the structure should remain as prescribed.

In this work hierarchy, the business case exists at the Initiative level. As we shall see however, this is not necessarily where the funding code is assigned.

Traditional funding model

In the traditional model, a business case is raised to deliver a project. When that business case is approved, funding is assigned to that project, typically using a project code. That project code will have a given budget associated with it, as well as forecast benefits. We can visualize this diagrammatically along these lines:

The funding code lasts for the duration of the project.

The Lean model

The world gets a little bit more complicated when we look at how we fund agile initiatives. We already know that we do not want to fund the initiative, we want to fund the team.

In this example, our initiative might be “Launch in the USA”. To achieve this initiative, we are going to need support from Marketing teams, Legal teams and Product teams.

We can visualize this diagrammatically like this:

In agile budgeting, funding codes attach to teams – not initiatives – enabling continuous delivery and iterative value realization. But that does not mean that we should not be putting them through investment governance. It simply means that the route they must take is a little different.

Using this hybrid funding approach, agile budgeting can support both legacy and product-led investment models, as illustrated here:

Budgeting across agile, waterfall, and hybrid

Most organizations start from the position that they would like to adopt agile delivery wholesale. There is certainly nothing in principle against this. Organizations must ensure however that they do not lose sight of what they are trying to achieve more broadly. That is to say – move faster, deliver more value, empower your teams and get closer to the customer.

Some initiatives/projects simply fit better within a waterfall mold. Agile budgeting doesn’t mean abandoning waterfall; it means budgeting by delivery method, aligning governance to the nature of work. For example, agile is typically more effective in a complex domain where learning is required. Waterfall can be more effective in a clear domain where the same work has been done before and hence can be replicated, repeated and scaled more effectively by a waterfall process.

Agile budgeting supports this mixed model by applying governance appropriate to the delivery context – rigorous financial tracking where needed, lightweight value-driven control where learning and iteration dominate.

💡 When thinking about what is right for your organization, be sure to pursue pragmatism over principle; trying to fit a round peg (naturally waterfall initiative) into a square hole (enforced agile framework) can act as an impediment to productivity, rather than a catalyst

One example might include an initiative to outsource a business process (AKA BPO). There are some very clear steps that such an initiative must undertake to ensure successful delivery. It probably starts with vendor selection and an RFP. Then move to agreeing commercials. This part of the initiative has a clear start and end, with success criteria and scope that can be deeply understood at the beginning of delivery. Setting clear milestones in this context is likely to be conducive to success.

Pilot agile budgeting in teams

Our experience is that the best way to approach agile budgeting is to start with a team, or a few teams as a pilot. After proving this out, ironing out the creases, and iterating the model to best fit your organization, roll it out further, to include additional teams. This can be helpfully thought of as using a textbook-Agile approach to the agile transformation itself. That is to say, start small, identify a pilot/PoC/MVP, iterate, refine and double down when you have found the winning formula.

There are also hybrid examples. For example, a telecoms provider who’s software engineering follows agile principles, but who’s network construction (i.e. towers, cables) is waterfall.

Implementing governance

Implementing agile budgeting requires adapting your governance structure to track funding, forecasts, and actuals without reverting to traditional cost-center logic. This step ensures that agile budgeting mechanisms like team-based funding and iterative prioritization are backed by traceable, auditable governance processes.

Demand management

Agile budgeting begins with a rethink of demand management – specifically, how funding flows through agile, waterfall, and hybrid initiatives. The demand management process must be able to account for the methodology that you are planning to use to deliver the initiative (e.g. agile, waterfall or hybrid). This segmentation ensures budgeting decisions are aligned to how the work will actually be delivered. Below you can see how this works, at a high level:

It is important that this split is clear and binary at the funding level. This point in the process is represented by the “Methodology review” step. Note that it is possible to have initiatives that are separated into their “traditional delivery” components and their “agile delivery” components. This adds complexity to the investment tracking, so this should only be done in cases where it is absolutely necessary.

An example of when this type of “hybrid initiative” might make sense is an initiative requiring predominately traditional delivery, but also requiring enabling work from an agile product team. Take GDPR compliance as an example of this. There is a clear, predefined scope that needs to be achieved, much of which will have a sequential (waterfall) delivery approach. An organization might choose to stand up a specific project team to deliver this. This project team might live outside of the agile teams. However, to deliver the project, changes may be required to the mobile app, and to the website. In this hypothetical example, the mobile app, and the website are both supported by dedicated agile teams.

Therefore the changes that are required to be made to these platforms should be delivered via the agile demand management and planning process.

💡 See how this works in Kiplot. Explore the Portfolio Kanban feature overview, and learn more about how it works.

Approval, prioritization and representative costs

Once demand is split, agile budgeting must quantify effort and translate it into cost without forcing teams to think in financial terms.

In the investment governance process illustrated above, we have assumed that the upper flow (building a traditional business case) is self-explanatory and well documented elsewhere. The lower flow (build value case) is where we will dig a little deeper.

In the diagram below, we have broken down the different steps that make up the value case creation process:

 

💡 Learn more by exploring the Kiplot prioritization feature overview.

1. Estimating initiatives

The first step in building the value case is to establish an estimate for the initiative. This should involve senior product owners, team members and architects who are sufficiently familiar with the technology, products and customers affected. The estimation process at this level is not fundamentally different to the way that a traditional initiative is estimated.

The objective is to establish a very rough order of magnitude to act as an indicative guide for the amount of effort the organization might expect to expend, to deliver it. It is likely that this estimate will be reviewed and refined over time.

Portfolio level estimation is challenging due to the insufficient amount of information available at this stage. Applying agile estimation concepts (typically practiced in lower level sprint planning) can be helpful here (e.g. Relative estimating using a known base and a range of numbers in the Fibonacci series). This rough-order estimate is foundational for agile budgeting and is refined iteratively as delivery evolves.

2. Calculating representative cost

If you want to be able to compare and prioritize the relative value of a series of proposed initiatives, the next step is to convert this effort estimate into a representative cost estimate. The purpose of doing this is to allow a like-for-like comparison at the point of prioritization. Without an indicative understanding of cost, you will be unable to objectively compare the relative business cases of a given initiative.

Note that the initiative may also include a set of costs that are fixed (e.g. recharges, capital costs etc).

It is important that this conversion is passive, automated and separated from the estimation process. It should be a mechanism that allows the estimate to be represented as a cost. Not a process that encourages product owners and/or technical architects to focus on cost at the point of estimation.

3. Value hypothesis

Having estimated the cost side of the equation, our next step is to look at the value side of the equation.

To keep things straightforward to begin with, you may wish to require all estimates to connect their value directly to profitability. For more mature organizations, you may allow value estimates to be provided against non-revenue benefits (e.g. more users using the Mobile App or Reduction in volume of calls to contact centers). Doing this can help teams to think in terms of direct impact to the customer. However, the organization must retain the ability at some point in the process to connect this “Why” to commercial gain (long term or short term) in terms of revenue gained, cost saved, or risk mitigated.

Agile budgeting allows organizations to run a portfolio of traditional initiatives in conjunction with agile initiatives. However, we know that we do not expect an Agile Initiative to maintain a “financial forecast” or be governed in terms of “budget” in the same way as a waterfall initiative. Instead, we expect the Initiative to be approved, and the work to deliver it to be allocated out to the teams required to deliver it.

Translating agile work into budget terms

Agile budgeting depends on mapping initiative-level metrics (budget, forecast, actuals) without requiring traditional project controls.

That presents a problem when we seek to track the inflight progress of an Agile Initiative in financial terms. In order to track holistic progress across the portfolio, we must establish equivalence across the attributes of a traditional initiative, and an agile initiative.

A straightforward example is,

💡 “Value hypothesis is to an agile initiative what the benefits case is to a traditional initiative”

In order to allow portfolio tracking, we must establish these equivalents across the other key financial lenses: Budget, Forecast and Actuals.

Budget: Initiative estimate is to an agile initiative what the budget is to a traditional project.

Forecast: The combined total of the estimates of the epics assigned to an initiative is to an agile initiative what the current financial forecast is for a traditional project.

Actuals: Time recorded against Epics within the Initiative is to an agile initiative what time recorded against the project is for a traditional project.

Traditional project governance

Agile initiative governance

Implementing agile budgeting at scale

Implementing lean financial governance requires a clear understanding and adaptation of both traditional and agile methodologies within your organization. By establishing equivalents between these approaches, such as aligning value hypotheses with benefits cases and converting effort estimates into representative costs, you can ensure effective and consistent portfolio tracking. This balanced approach allows you to manage a diverse set of initiatives while maintaining financial accountability and strategic alignment across the board.

Explore how Kiplot’s budgeting features support enterprise-scale agile delivery.