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.
CapEx and OpEx
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 the development of intangible assets—such as software, intellectual property, and patents.
Enterprises fund a SAFe portfolio to support 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. In accordance with accounting standards, some enterprises may capitalize some percentage of the labor involved in creating software for sale or internal use.
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 stage gates. This means the enterprise is faced with a new problem: how to treat these costs effectively in an Agile program. If finance is unable to reconcile the change in methodology, it may mandate that work continue under waterfall development. Or it may decide to expense all Agile development labor costs. Neither approach is ideal.
This article provides the strategies that 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, and there are many viewpoints. References 2, 3, and 4 below provide additional perspectives. Lean-Agile change agents should engage early with business and financial stakeholders to establish an understanding of 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 varies by country, industry, and individual company policy. (For example, suppliers to the U.S. federal government have an entirely different set of rules.) Moreover, even when subject to the U.S. Financial Accounting Standards Board (FASB) guidelines, under the general GAAP ‘principle of conservatism,’ some companies choose not to capitalize software development costs at all (see Reference 5 for an example). Each enterprise is responsible for the appropriate implementation of financial accounting for capitalization of development costs.
Enterprises provide funding to a SAFe Portfolio to support the development and management of a set of Solutions. Within the portfolio, allocating funds to individual Value Streams is the responsibility of Lean Portfolio Management (LPM), who allocates 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:
- The burden for operating personnel, sales, and marketing
- General and administrative costs
- Supplies and maintenance
- Other expenses related to operating a business or an asset of the business
Costs are recorded and expensed in the period in which they occur.
Most often CapEx reflects the monies required to purchase, upgrade, or fix tangible physical assets, such as computing equipment, machinery, or other property. In this case, the cost of purchase 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 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/or the financial results of the portfolio may not be accurate.
In particular, capitalizing 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 U.S. Financial Accounting Standards Board (FASB) provides guidance for Generally Accepted Accounting Principles (GAAPs) for U.S. companies that report financials in the public interest. This includes those that report publicly under U.S. Securities and Exchange Commission regulations. Similar organizations exist in other countries. For example, the U.K. Financial Reporting Council (FRC) provides policies that are largely similar to those of FASB. In addition, the U.S. Federal Government has different standards under the Federal Accounting Standards Advisory Board.
For U.S. companies operating in the private and public reporting sectors, U.S. FASB 86 [Ref 1] provides accounting guidelines for the costs of computer software to be sold, leased, or otherwise marketed. 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. Thereafter, software production costs may be capitalized and subsequently 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 life of the product. 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 SOP 98-1 (also see subtopic ASE 350-40 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 taken into consideration.
Capitalization vs. Expense Criteria
In general, FASB 86 requires that a product must meet the following criteria to capitalize ongoing development costs:
- The product has achieved technical feasibility.
- Management has provided written approval to fund the development effort.
- Management has committed the resources to development.
- Management is confident that the product will be successfully developed and delivered.
Before software can be capitalized, finance departments typically require documented evidence that these specific activities have been completed. Once these criteria are met, further development costs may be subject to capitalization, as described in Table 1:
Table 1. Categories of expensed and potentially capitalized costs
Capitalization Triggers in Waterfall Development
Historically, capitalization has been applied in the context of waterfall/stage-gate development. Waterfall development has a well-defined “up-front phase” during which requirements are developed, the design is produced, and feasibility is established. For those projects that receive further approval, the requirements and design milestones often serve as stage gates for starting capitalization, as shown in Figure 1.
Agile Development Capitalization Strategies in SAFe
In Agile, however, requirements and design emerge continuously, so there’s no formal gate to serve as an official starting point for capitalization. That does not mean, however, that projects fund themselves. Instead, the 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 Program Increment (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 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 various portfolio initiatives (Epics) that work their way through the Portfolio Kanban. This 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 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 the may arise locally. In addition, maintenance, infrastructure work, etc., also occur during the period. Figure 2 illustrates these concepts.
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 enhance functionality.
This work can be easily identified and tracked for potential CapEx treatment. To do so, accounting fiduciaries work with Product Management to identify these features in the Program Backlog. Those selected are ‘typed’ for potential CapEx treatment; that creates the basic tracking mechanism. Thereafter, 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 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, refactors, and any other work—may not be. Agile Lifecycle Management (ALM) tooling can support the definition, capture, and work associated with implementing stories. By associating stories with features when applicable in the tooling (typically called “parenting”), the work related to feature development can be identified for potential CapEx treatment. Various query functions in the ALM tool can help automate the needed summary calculations. Table 2 indicates three of the possible mechanisms for calculating the percentage of work that may be a candidate for CapEx treatment.
I. By Story Hours
The most granular means for capturing labor effort is have to 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 overhead and thus reduces value delivery 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 quickly assess the total cost that may be subject to CapEx treatment.
Note: During planning, some Agile Teams break stories into tasks and estimate and update task hours accordingly. Method I requires only that actual total team hours be recorded to the story; tasking is not mandatory.
II. By Story Points
Story points are the ubiquitous currency of Scrum. Scrum teams estimate stories in points and update their estimates to actuals to improve future estimates. Although story points are relative, and not absolute units of measure, they’re all that’s necessary. The enterprise needs only to know the percentage of story points allocated to stories that have CapEx potential, over the total story points delivered in any accounting period. Conversion to actual costs is handled in the same way as for example I, above. This is a low-friction, low-overhead method that generally does not create any additional burden on teams, other than the need to be sure to update estimates to actuals for each story completed. Again, ALM tooling typically supports the recording and automated calculation of such measures.
Note: In order to compensate for the relative nature of story points, which can vary from team to team, SAFe suggests a means for normalizing story point estimating across teams as part of the common economic underpinning for an ART.
III. By Story Count
The methods above provide a fairly granular means of encoding work to the efforts that might 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 many hundreds of stories, in various types and sizes. For example: 10 teams, 10 stories per Iteration, over 4 iterations, yield 400 stories per PI. Sizing a story is not biased by an understanding of the potential for CapEx treatment of a story (the teams need not even be aware of the difference), and therefore stories sizes will average out over time. In addition, over time the CapEx and associated depreciation schedules resolve to expense all development anyway.
Thus, near-term perfection is not necessarily the goal, as it’s probably false precision anyway that may come at too high a cost. This suggests that simply counting stories by type is a fair proxy for the amount of effort devoted to potential CapEx stories. In a manner similar to methods I and II above, this percentage can then be used to determine the CapEx potential in a given accounting period. Some Agilists have reported that this percentage approach is being applied on new Lean-Agile development initiatives (sometimes based simply on initial capacity allocation; see Program Backlog). While subject, appropriately, to occasional audits, this provides a fairly friction-free approach that allows teams to focus exclusively on value delivery.
What Specific Labor Efforts May Be Subject to CapEx Treatment?
There is one final aspect left to discuss: What labor elements may be applied to CapEx treatment? Again, the answer is highly specific to the actual enterprise. However, within the Agile development world, the following guidelines are often applied:
The salaries of Agile Team members who are directly involved in refining, implementing, and testing stories may be subject to CapEx, as is largely consistent with existing waterfall practices. This may include software developers, testers, user experience, and subject matter experts.
In addition, Product Owners (POs) and Scrum Masters are part of the 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 additional average cost burden on a CapEx story.
Further, not all work for a feature is performed solely by Agile Team members. System Architects, System Teams, and DevOps contributors also contribute to the features under development; some portion of their cost may be subject to CapEx as well.
Finally, in the larger value streams, additional roles contribute to value creation via Pre- and Post-PI Planning, creation and maintenance of Solution Intent, and the Solution Demo. While further removed from the specific implementation tasks, all of these activities and roles provide value. So their potential for CapEx treatment is appropriate, at the discretion of the enterprise.
Learn More FASB 86 Summary at fasb.org/summary/stsum86.shtml.  Reed, Pat, and Walt Wyckoff. Accounting for Capitalization of Agile Labor Costs. Agile Alliance, February 2016.  Greening, Dan. Why Should Agilists Care about Capitalization? InfoQ, January 29, 2013.  Connor, Catherine. Top 10 Pitfalls of Agile Capitalization. Rally, February 2016.  Footnote from a U.S. 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 costs of certain third-party contractors, as well as allocated overhead. Research and development costs related to the development of our software products are generally expensed as incurred. Development costs that have qualified for capitalization are not significant.”
Last update: 1 August, 2017