Lean-Agile Leaders need to understand an Enterprise’s current software development capitalization practice, as well as how to apply these principles in Agile development. Otherwise, the transformation to Agile may be blocked or, alternately, the company may not be able to correctly account for development expense.

—SAFe advice

CapEx and OpEx

Note: This article is part of Extended SAFe Guidance and represents official SAFe content that cannot be accessed directly from the Big Picture.

Capital Expenses (CapEx) and Operating Expenses (OpEx) describe Lean-Agile financial accounting practices in a Value Stream budget. In some cases, CapEx may include capitalized labor associated with developing intangible assets—such as software, intellectual property, and patents.

Enterprises fund a SAFe portfolio to support the development of the technical Solutions that allow the company to meet its business and financial objectives. These Lean Budgets may include both CapEx and OpEx elements. Following accounting standards, some enterprises may capitalize some percentage of the labor cost for the sale or internal use of software development.

Although software capitalization practices are well established in many enterprises, they’re typically based on waterfall development, in which up-front requirements and design phase gates may represent the events that can trigger CapEx treatment. In Agile development, however, these are not relevant phase gates. The enterprise faces a new problem: effectively treating CapEx for Agile development methods. If finance cannot reconcile the change in methodology, it may mandate that work continues under waterfall development. Or it may decide to expense all Agile development labor costs. Neither approach is ideal.

This article provides the strategies SAFe enterprises can use to categorize labor costs in Agile development, some of which may be subject to CapEx treatment. However, this is an emerging field of understanding with many viewpoints. References [2] and [3] below provide additional perspectives. Lean-Agile change agents should engage with business and financial stakeholders early to understand how the new way of working may affect accounting procedures.

Disclaimer: The authors have no formal training or accreditation in accounting. The treatment of software costs and potential for capitalization vary by country, industry, and individual company policy. (For example, suppliers to the US federal government have an entirely different set of rules.) Moreover, even when subject to the US Financial Accounting Standards Board (FASB) guidelines, under the Generally Accepted Accounting Principles (GAAP) principle of conservatism, some companies choose not to capitalize software development costs at all [4]). Each enterprise is responsible for the appropriate implementation of financial accounting for the capitalization of software development costs.

Details

Enterprises provide funding to a SAFe portfolio to support developing and managing solutions. Within the portfolio, allocating funds to individual value streams is the responsibility of Lean Portfolio Management (LPM), which gives the necessary funding for each value stream in a portfolio. A budget for a SAFe portfolio may include both CapEx and OpEx elements. OpEx records the ongoing costs of running a product, business, or service. These include:

  • Salaries
  • The burden for operating personnel, sales, and marketing
  • General and administrative costs
  • Training
  • Supplies and maintenance
  • Rent
  • Other expenses related to operating a business or an asset of the business

OpEx is recorded and expensed in the period in which they occur.

CapEx most often reflects the funding required to purchase, upgrade, or fix tangible physical assets, such as computing equipment, machinery, or other property. In this case, the purchase cost is put on the balance sheet as an asset and then expensed on the income statement over the useful life of that asset. In addition, in some cases, some of the labor costs associated with the development of intangible assets, such as patents and software, may also be subject to CapEx treatment. In this case, CapEx may include salaries and direct burden, contract labor, materials, supplies, and other items directly related to the solution development activities.

Portfolio stakeholders must understand both CapEx and OpEx so that they are included in the Economic Framework for each value stream. Otherwise, money may not be spent in the right category, and the financial results of the portfolio may not be accurate.

In particular, capitalizing on some of the costs of software development can have a material effect on financial reporting. That is the topic of the remainder of this article.

Accounting for Software Development Costs

Rules for capitalization of software assets vary by country and industry. In the United States, the US Financial Accounting Standards Board (FASB) guides Generally Accepted Accounting Principles (GAAP) for US companies that report financials in the public interest. This includes those that report publicly under US Securities and Exchange Commission regulations. Similar organizations exist in other countries. For example, UK Financial Reporting Council (FRC) provides policies broadly similar to FASB. In addition, the US federal government has different standards under the Federal Accounting Standards Advisory Board.

For US companies operating in the private and public reporting sectors, US FASB 86 provides accounting guidelines for the costs of computer software to be sold, leased, or otherwise marketed [1]. FASB 86 states that costs incurred internally in creating a computer software product must be expensed when incurred as research and development until technological feasibility has been established. After that, software production costs may be capitalized and reported at the lower of either the unamortized cost or the net realizable value. Capitalized costs are amortized based on current and future revenue for each product, with an annual minimum equal to the straight-line amortization over the remaining estimated economic product life. For these purposes, a software product is defined as either a new product or a new initiative that changes the functionality of an existing one.

Software Classifications under FASB 86

There are three primary classifications of software development under FASB 86:

  • Software for sale – Software developed for sale as a stand-alone or integrated product, typically by independent software vendors (ISVs)
  • Software for internal use – Software developed solely for internal purposes or in support of business processes within an enterprise, which is further described in Statement of Position (SOP) 98-1 (also FASB Accounting Standards Update 350-25  for fees paid in Cloud Computing)
  • Embedded software – Software as a component of a tangible product needed to enable that product’s essential functionality

Capitalization standards are treated differently within these categories, so the relevant guidelines must be considered.

Capitalization versus Expense Criteria

In general, FASB 86 requires that a product must meet the following criteria to capitalize on ongoing development costs:

  • The product has achieved technical feasibility
  • Management has provided written approval to fund the development effort, committed the people and resources to the development, and is confident that the product will be successfully developed and delivered

Before software can be capitalized, finance departments typically require documented evidence that these activities have been completed. Once these criteria are met, further development costs may be subject to capitalization, as described in Figure 1.

Figure 1. Categories of expensed and potentially capitalized costs
Figure 1. Categories of expensed and potentially capitalized costs

Capitalization Triggers in Waterfall Development

Historically, capitalization was applied in the context of a waterfall or phase-gate development process. Waterfall development had a well-defined up-front phase, during which requirements were developed, the design was produced, and feasibility was established. For those projects that received further approval, the requirements and design milestones often served as phase gates for starting capitalization, as shown in Figure 2.

Figure 2. Early waterfall phases establish feasibility and trigger management commitment to funding
Figure 2. Early waterfall phases establish feasibility and trigger management commitment to funding

Agile Development Capitalization Strategies in SAFe

In Agile, however, requirements and design emerge continuously, so there’s no formal phase gate for capitalization to serve as an official starting point. That does not mean, however, that projects fund themselves. Instead, SAFe enterprise organizes around long-lived flows of value in value streams. The personnel and other resources of an Agile Release Train (ART), operating on a fixed PI cadence, implement them.

The majority of the work of most ARTs is typically focused on building and extending software assets that are past the point of feasibility analysis. They generally do this by developing new features for the solution. Since Features increase the functionality of existing software, the User Stories associated with those features constitute much of the work of the ART personnel. Therefore, this labor may be subject to potential capitalization.

The ARTs also help establish the business and technical feasibility of the portfolio initiatives (Epics) that work through the Portfolio Kanban. This feasibility work is somewhat analogous to the early stages of waterfall development and is typically expensed up until the ‘go’ recommendation when new feature development would begin.

This means that both types of work are typically present in any PI—and, by extension, any relevant accounting period. Much of this is new feature work that increases the functionality of the existing software. Other work includes innovation and exploration efforts. These may be initiated from the portfolio Kanban—as part of the research and feasibility for potential new portfolio-level epics—or they may arise locally. In addition, maintenance and infrastructure work also occur during the period. Figure 3 illustrates these concepts.

Figure 3. Many types of work occur within a given PI timebox
Figure 3. Many types of work occur within a given PI timebox

Categorization of Features for OpEx and CapEx

Creating new features for the solution is part of implementing new projects and enhancing existing products. By their very definition, features provide enhanced functionality.

Features can be easily identified and tracked for potential CapEx treatment. To do so, accounting personnel works with Product Management to categorize or (flag) features for potential CapEx treatment, creating the primary tracking mechanism. After that, teams associate new stories with those features and perform the essential work of realizing the behavior of the features by implementing stories in the new code base.

Applying Stories to CapEx and OpEx Treatment

Most stories contribute directly to the new functionality of the feature; the effort for those stories may be subject to CapEx treatment. Others—such as Enabler stories for infrastructure, exploration, defects, refactoring, and any other work—may not be. Agile Lifecycle Management (ALM) tooling can support the definition, capture, and labor of implementing stories.

The work related to feature development can be identified for potential CapEx treatment by associating child stories with their parent feature when applicable in the tooling. Various ALM reporting tools can help automate the needed summary calculations.

Figure 4 indicates three possible mechanisms for calculating the percentage of work that may be a candidate for CapEx treatment.

Table 4. Possible mechanisms for tracking efforts associated with CapEx stories
Figure 4. Possible mechanisms for tracking efforts associated with CapEx stories

By Story Hours

The most granular means for capturing labor effort is to have team members record their hours against each story. Although there’s some overhead, many teams do this anyway because of traditional time-tracking requirements for job costing, billing, estimating, and other needs. However, this should not be the default mode for CapEx, as it incurs significant overhead and reduces velocity. The rest of the calculation is straightforward: the CapEx potential percentage is simply the percentage of hours recorded for CapEx features divided by the total of all hours invested in any period. After converting hours worked to cost, the enterprise can assess the total cost subject to CapEx treatment.

(Note: Some Agile Teams break stories into tasks during planning and estimate and update task hours accordingly. This method only requires the total team hours for the story; tasking is optional.)

By Story Points

Story points are the most common way Agile Teams estimate their work effort. Many teams update their estimates to actuals to improve future estimates. Although story points are relative, not absolute, units of measure, they’re all that’s necessary. The enterprise only needs to know the percentage of story points with CapEx potential divided by the total story points completed in any accounting period. Conversion to actual costs is handled in the same way as for the preceding example. This low-friction, low-overhead method generally does not create any additional burden on teams other than the need to update estimates to actuals for completed stories. Again, ALM tooling typically supports the recording and automated calculation of such measures.

(Note: To compensate for the relative nature of story points, which can vary from team to team, SAFe suggests a method for aligning story point estimates within an ART as part of the standard economic underpinning).

By Story Count

The methods above provide a reasonably granular means of categorizing work to be capitalized. But then there’s the labor of entering and capturing the data, and that extra work does not, by itself, deliver end-user value. Given the scope of the typical ART in the enterprise, there may be an easier way.

In a single PI, it’s not unusual for an ART to implement hundreds of stories in various types and sizes (for example, ten teams, ten stories per Iteration, over four iterations, yielding 400 stories per PI). Story sizes will average over time.

Near-term perfection is not necessarily the goal, as this likely false precision comes at too high a cost. Simply counting stories by type is a fair proxy for potential CapEx stories. This percentage can determine the CapEx potential in a given accounting period like the first two methods above. Some Agilists say that this percentage approach is being applied to new Lean-Agile development initiatives (sometimes based simply on initial capacity allocation described in the ART Backlog article. While subject, appropriately, to occasional audits, this method provides a reasonably friction-free approach that allows teams to focus exclusively on value delivery.

What Labor is Subject to CapEx Treatment?

Within the Agile development world, the following guidelines are often used:

  • Agile team members’ salaries directly involved in refining, implementing, and testing stories may be subject to CapEx, as it is mainly consistent with existing waterfall practices. This may include software developers and testers User Experience (UX), and other subject matter experts.
  • Product Owners (POs) and Scrum Masters/Team Coaches are part of the Agile team and directly contribute to story definition and implementation. This indirect labor is directly associated with new value delivery and, thus, may be appropriate for CapEx treatment. This can be accomplished by adding an average cost burden to a CapEx story.
  • System Architects, System Teams, and IT Operations also contribute to feature development. Some portion of their cost may be subject to CapEx as well.
  • Additional roles in the Solution Train may contribute to value creation during the following types of activities: Pre-Plan, Coordinate and Deliver, design and maintenance of Solution Intent, and the Solution Demo. Since these activities and roles provide value, their potential for CapEx treatment may be appropriate at the discretion of the enterprise.

Learn More

[1] FASB 86 summary at https://asc.fasb.org/1943274/2147482658/350-40-25

[2] Reed, Pat, and Walt Wyckoff. Accounting for Capitalization of Agile Labor Costs. Agile Alliance, February 2016.

[3] Greening, Dan. Why Should Agilists Care about Capitalization? InfoQ, January 29, 2013.

[4] Footnote from a US public reporting software company’s Form 10-K filing, highlighting a policy of not capitalizing software development expense: “Research and development expenses primarily consist of personnel and related costs of our research and development staff, including salaries, benefits, bonuses, payroll taxes, stock-based compensation, and expenses of certain third-party contractors, as well as allocated overhead. Research and development costs related to creating software products are generally expensed as incurred.

Last update: 2 March 2023