CapEx vs OpEx in Agile: Bridging Finance and Flow

In many organisations adopting agile ways of working, a familiar tension surfaces:

“Our finance team says we still need to separate CapEx and OpEx. But how can we do that when work flows continuously through long-lived squads?”

It’s a good question — and one that reveals more about the assumptions baked into legacy financial structures than about what’s actually needed for compliance or good governance.

Why This Tension Exists

In traditional project-based delivery, CapEx and OpEx separation was straightforward:

• CapEx (capital expenditure) applied to work that created a long-term asset, such as a software system or major enhancement.
• OpEx (operating expenditure) covered maintenance, support, and ongoing operational activities.

But agile delivery isn’t project-based. Instead of passing work through gated phases, long-lived cross-functional squads deliver incrementally and continuously. Value emerges iteratively. Phases blur. Asset creation happens over time, not in a defined “build” window.

As a result, agile teams are often asked to reverse-engineer artificial stages — just to satisfy a financial model that no longer reflects how work is done.

You Don’t Need a Project to Capitalise Work

A common myth is that capitalisation requires a formal project plan or phase gate process.

In reality, financial frameworks such as IFRS (International Financial Reporting Standards) and US GAAP allow for the capitalisation of agile work — provided the intent and output meet the usual criteria:

• The work contributes to an identifiable product or asset
• It creates future economic value
• It is traceable

You don’t need a Gantt chart to capitalise work. You need clarity of purpose, delivery artefacts, and a consistent classification approach.

How Agile Teams Can Support CapEx/OpEx Requirements

Here are four strategies that organisations I work with have successfully used:

1. Classify by Intent, Not Phase

Work should be classified according to what it aims to achieve, not where it sits in a delivery process. For example:

CapEx:

• Feature development
• Technical spikes that feed directly into product delivery
• Architecture or infrastructure work that creates or enhances capability

OpEx:

• Production support and maintenance
• Research or exploration with no defined output
• Discovery, training, or operational tasks

2. Use Story or Epic-Level Tagging

With a well-maintained backlog, tagging stories or epics as CapEx or OpEx is often sufficient. Most agile tools (e.g. Jira, Azure DevOps) can support this, especially when paired with sprint-level reporting or light time logging.

3. Apply Allocation Ratios When Needed

Where precise tagging isn’t practical, many organisations use squad-level allocation models. For instance, a team may operate on a 70% CapEx / 30% OpEx basis, based on historical work mix.

This avoids burdensome tracking while still giving Finance the visibility they need.

4. Partner with Finance

Work with finance colleagues to co-create clear definitions and tracking standards that reflect both policy and real delivery practice. Many finance teams are open to this discussion — especially when they see that agile teams can offer more frequent, traceable evidence of value than traditional projects.

What Happens When We Get This Wrong

If we try to make agile teams fit into old financial governance models, we often see:

• Teams introducing artificial “design” and “build” phases to capitalise work
• Poor or inconsistent reporting
• Delayed delivery due to process friction and tracking overhead

But when we get it right:

• Finance gets the transparency and compliance they need
• Teams retain flow and autonomy
• Everyone aligns around a shared understanding of how value is delivered

Final Thought

Agile delivery and financial accountability are not in conflict — but they do require new patterns of collaboration.

If we want to fund and govern adaptive work effectively, we must stop asking agile teams to behave like projects.

Instead, we should evolve our financial practices to reflect how value is truly created: iteratively, collaboratively, and in flow.