How to Stop Leaving Software CapEx on the Table With Agile and DevOps

Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure (CapEx) dollars on the table.

It should come as no surprise that most Agilists care more about software development than accounting. In many organizations the difference is critical. CapEx is capital spending on investments in the company’s future, such as new infrastructure, capabilities, and software. OpEx is operational spending related to running what you have built. Most importantly, CapEx is a clear signal of how much a company is prepared to invest in its future. Software development investment is also an unambiguous sign to industry and investment analysts that the company is competitive in the digital economy, which drives investment.

Traditional accounting leaves software development CapEx on the table

Software development costs have traditionally been capitalized, while research and operations are operational expenditures. The challenge has always been the myth that operations is only bugfixes, upgrades, and other operational expenditures. However, research shows that most post-release work on developed solutions is the development of new features and changes to support material changes in the business. While projects could bundle some of these changes into capital expenditure, much of the business-as-usual work that goes on leaves capital expenses on the table because the work is lumped together as maintenance-related OpEx.

Here comes Agile…

The use of Agile practices is the tipping point between project-centric and product-centric delivery. If your organization is still doing project-based Agile (Wagile, WaterScrumFall, or Fragile, as some of the more cynical Agilists call it) your accountants can carry on as if nothing has changed. The shift to standing product teams and DevOps shatters those comfortable boundaries, leaving delivery leaders scrambling to account for CapEx versus OpEx.

Agile and DevOps practices are not the problem; they are the solution

Agile and DevOps are often thought to be “breaking” accounting. The truth is that they hold the key to unlock the previously lost software CapEx – in particular, the practice of building a functionally decomposed backlog of features or user stories classified by the type of work. For example:

User Story

Spike

Definition

Literally “a promise for a conversation” (Cockburn, 1999), a user story is the most commonly used artifact for organizing work in Agile.

A story that is too large or complex and cannot be estimated without prior time-boxed investigation.

CapEx Scenario

The story is used to add functionality that enables users to do something they haven’t done before.

The team need to evaluate competing innovative approaches to automate a process.

OpEx Scenario

The story guides refactoring that improves the performance of a production system.

The team needs to investigate the source of intermittent failures in a production system.

Tag them all and the accounting takes care of themselves.

Breaking the boundary between Dev and Ops unlocks additional CapEx

Capital work done in operational use of the software is not only the implementation of new features. DevOps engineers are charged with building infrastructure as code – converting manual processes to automatically executed software. This fits the definition of software for internal use laid out in the Generally Accepted Accounting Principles (GAAP). This not only makes the company look good financially but also gives you a new way to make the case for funding from a pool of money traditionally inaccessible to operational software teams.

Success requires disciplined backlog management, roadmapping, and metrics

Using your product backlog to identify teams’ CapEx and OpEx work requires discipline:

• Product owners need to tag backlog items to identify if they are capital (new development) or operational (bugfix, maintenance, etc.) expenses (see Build a Better Backlog).
• Product owners need to roadmap features and stories to releases to trigger capitalization (see Build a Product Roadmap and Build a Product Canvas).
• Teams need to estimate the size of work (see Estimate Software Delivery With Confidence) and measure actual rather than estimated velocity (see Select and Use SDLC Metrics Effectively).
• Tracking all of this with a product management or Agile work management tool such as Jira, Rally, or VersionOne makes this all easier! (See Automate Your Software Delivery Lifecycle.)

You do not need to track time!

Task-level time estimates can be a valuable tool to help Agile teams build discipline. Unlike Waterfall, you should not need to do role-based time tracking to do Agile accounting. Story points are a useful Agile estimation and measurement tool that allows you to abstract out time while still accurately measuring the work you deliver. The key consideration is that you can only capitalize work that has been completed when you release it to production. Because the type of product backlog item defines whether it is CapEx the accounts can readily capitalize with a short list of items:

• Full-Time Team Run Rate (salary, you should know this)
• Contract Run Rate (contract $, you should know this)
• Sprint/Release Length in Weeks (you should know this)
• % CapEx (you should tell them this)
• % Idle and Administrative Time (accounting should have defined this for full-time employees)

Or:

Here is an example using story points:

Sprint-Based Team

Release-Based Team

Full-Time Run Rate

$400K/annum

Idle and Admin

0.25

Adjusted FTRR

$300K/annum

Contract Run Rate

$250K/annum

Length

2 weeks

6 weeks

Total Velocity

50 SP

650 SP

CapEx Story Points

30 SP

400 SP

OpEx Story Points

20 SP

250 SP

% CapEx vs. OpEx

60%

62%

Capitalization

$12,692.31 over 2 weeks

$39,346.15 over 6 weeks

Use when

Your team releases code to production every two weeks.

Your team releases one or more features to production at a planned milestone.

The advantage of this approach is that it allows you to ignore variations in velocity and release cadence between teams, which reduces your administrative overhead to simply reporting whenever you happen to release.

YOU MUST WORK WITH ACCOUNTING!

I prefer not to use all caps, but every rule has an exception. Every finance department defines how the organization will apply the GAAP to their financial operations. Agile creates the opportunity for change and more accurate tracking of capitalization. The decision to take advantage of this and how to implement it lies with the finance department, not IT.

Our Take

Agile represents a golden opportunity for organizations to manage software CapEx versus OpEx expenditures accurately and effectively. If you have implemented Agile, it is time to engage with accounting to define how you can take advantage of the opportunity created by product backlog item-level capitalization.

---

Want to Know More?

Do you need help getting started? Book a call for yourself and a partner from accounting to discuss how to make this work in your organization!