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 Abstract
Enterprises provide funding to a SAFe portfolio to support development of the technical Solutions that enable the enterprise to meet its business and financial objectives. These Budgets may include both Capital Expense (CapEx) and Operating Expense (OpEx) elements. In accordance with accounting standards, enterprises may capitalize (CapEx) some percentage of the labor involved in creating software for sale or internal use.
While software capitalization practices are well established in many enterprises, they are typically based on waterfall development, in which case up-front requirements and design phase gates may represent the events that can trigger CapEx treatment. In Agile development, however, these are typically not relevant stage gates. The enterprise is then faced with a new problem, which is how to apply effective treatment of these costs in an Agile development paradigm. If finance is unable to reconcile the change in method, then one of two things may happen: 1) They will block Agile development and mandate continued work under waterfall development, or 2) they will expense all Agile development labor costs—neither of which optimizes economics over time.
This article provides some 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.
Disclaimer: The authors have no formal training nor accreditation in accounting. The treatment of software costs and potential for capitalization treatment varies by country, by industry (for example, while many companies in the U.S. are subject to one set of rules, suppliers to the U.S. federal government have an entirely different set of rules), and even by individual company policy. Moreover, even when subject to the FASB guidelines, under the general GAAP “principle of conservatism,” some companies choose not to capitalize software development costs at all (see Ref 5 for an example).
The responsibility for appropriate implementation of financial accounting for capitalization of development costs rests with each enterprise. 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.
Enterprises provide funding to a SAFe Portfolio to enable the development and management of a set of Solutions. Within the portfolio, allocation of funding to individual Value Streams is under the auspices of Program Portfolio Management, who allocate the funding necessary 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 costs include salaries and burden for operating personnel, sales, and marketing; general and administrative costs; training; supplies and maintenance; rent; and other expenses related to operating a business or an asset of the business. These costs are recorded and expensed in the period in which they occur.
- CapEx most typically 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, 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 as part of 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 will not be as intended.
In particular, capitalization of 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 U.S., 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, including 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 within the governance of 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 guidelines for accounting 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 that is 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, in order to capitalize development costs, FASB 86 requires that a product must meet the following criteria:
- 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 capitalization of software can begin, 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 can be seen in Figure 1.
Agile Development Capitalization Strategies in SAFe
In Agile, however, requirements and design emerge continuously, so there is no formal gate to serve as an official prelude to capitalization. However, that does not mean that projects fund themselves. Instead, the SAFe enterprise organizes around long-lived flows of value in value streams, which are implemented by the personnel and other resources of an Agile Release Train (ART), which operates on a fixed Program Increment cadence.
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 do this in large part 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, and therefore the labor for same may be subject to potential capitalization.
The ARTs are also directly involved with establishing 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, at which time new feature development begins.
This means that both types of work are typically present in any program increment (and, by extension, any relevant accounting period). Much of this work is “new feature work,” 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 it 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
The work of implementing new projects and enhancing existing products is encapsulated in the creation of new Features for the solution, which, by their very definition, 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 such features in the Program Backlog. Those selected are “typed” for potential CapEx treatment; that creates the basic tracking mechanism for effort. 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. Other stories, 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 (typically called “parenting”) in the tooling, the work related to feature development can be identified for potential CapEx treatment. Various query facilities 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 to have individuals on the team record actual hours against each story. Although there is 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 thereby 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 estimating and tracking currency for work in Scrum. (Note: This method may or may not pertain to SAFe teams applying Kanban, as Kanban teams do not always use story points.) Scrum teams estimate stories in story points and update their estimates to actuals to improve future estimates. While story points are relative, not absolute, units of measure, they are all that is necessary, as 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 I, above. This is a low-friction, low-overhead method that does not generally 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, as described in SAFe Scrum.
III. By Story Count
The methods above provide a fairly granular means of encoding work to potentially capitalizable efforts. But there is work involved in 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 is not unusual for an ART to implement many hundreds of stories (example: 10 teams, 10 stories per Iteration, over 4 iterations, yields 400 stories per PI) of various types and sizes. 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 is probably false precision anyway and may come at too high a cost. This yields a suggestion 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 those outlined for I and II, 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 even more simply on initial capacity allocation; see Program Backlog). While appropriately subject to occasional audit, this provides an essentially 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 specific 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 software developers, testers, User Experience, subject matter experts, and other 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.
- In addition, Product Owners 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, as such, 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, and 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 activities, all of these activities and roles provide value, so their potential for CapEx treatment is at the discretion of the enterprise.
 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: 23 February 2016