This article is the third in a series about how organizational misalignments impede the adoption and successful use of agile through the enterprise value chain. In this blog posting, I address one of the most common issues that companies face: misunderstanding how to do cost accounting on agile projects to ensure fiscally responsible financial reporting.
My Experience with This Issue
Let me start by confirming I am neither a Certified Public Accountant (CPA) nor a tax expert. That being said, I do have on-the-ground experience with cost accounting and financial reporting in agile and non-agile environments—both as a coach and also in my executive-level positions at IBM and nine startup companies.
Defining Terms: Capitalizing vs. Expensing
Before discussing the specifics of the cost-accounting misalignment, I need to first establish some terminology. Consider the basic equation:
profit = revenue – expenses
Proper financial reporting requires that we appropriately account for the expenses part of this equation. Put simply, finance groups have two ways to calculate expenses: capitalize or expense.
Say you spend $50k to buy or build something that either immediately generates revenue or eventually might generate revenue. Further assume that in the same year you spent the $50k you also generated $150k in revenue (either as a direct result of the $50k expenditure or from other sources). You have two different ways to account for this $50k cost.
- You can expense the cost (operational expense) of building or buying the asset, meaning you subtract the total amount ($50k) from the annual revenue ($150k), to arrive at a profit of $100K (assuming no other expenses, of course!).
- Alternatively, if you are creating a long-term asset, you might be able to capitalize the cost (capital expenditure). When you capitalize expenses, you don’t offset annual revenues ($150k) by the entire cost of the asset ($50K) in the year you purchased or built the asset. Instead you list the purchase as an asset on your balance sheet and then each year (through depreciation) you offset revenue on your income statement against that year’s depreciated amount.
So, if you straight-line depreciate the asset over five years (assuming your capitalization period started in Year One), you would show an expense of only $10k in the year in which you purchased or built the asset. Then, for each of the next four years, you would show an additional $10k expense. So, Year One profit in this case would be $140K ($150k - $10k), which is $40k higher in Year One than if you had expensed the entire cost upfront.
An initial observation based on this example is that if we capitalize the cost instead of expensing it, our company looks more profitable (Year One profit of $140k vs. $100k), which has its advantages. To publicly traded companies, more profit often means a higher share price. To private companies, more profit might yield more favorable investment or financing terms. At the same time, higher profits also have their disadvantages, including the potential for higher taxes.
Choosing how to account for costs can be complicated—and I certainly don’t mean to suggest that there is always a single desirable way to classify every expense. Rather each company should make an informed decision based on its own objectives and compliance with tax laws.
With that being said, I do want to dive a bit deeper into the problem of higher profits yielding higher taxes. Often when developing a new product, revenues may not be high during Year One, when the initial investment costs ($50k) are incurred. In fact, a company is not necessarily immediately generating any revenue based on the expenditure—it might take some time for an investment to bear fruit.
So, if you expense the cost, the entire $50K, in Year One, you might not have much revenue to offset the cost. What often happens, then, is that later on, when your revenues increase, you don’t have any of that $50k expense left to offset those higher revenues, which will cost you at tax time. Keep in mind, too, that most taxing jurisdictions easily and happily tax profits but make it difficult to benefit from losses by reducing your future years’ profits.
All that is to say that if you expense the full cost early, it can lead to both an overpayment of taxes and choppy looking financial (P&L) statements. Nobody wants to overpay taxes; and most investors (and therefore companies) prefer smooth-looking financial statements, where revenue and expenses aren’t so unevenly distributed.
To bring this discussion back out of the realm of accountants, my main point is that, generally speaking, if you expense everything upfront, you run the risk of overpaying on taxes and understating your company’s value.
Agile Ignorance, Conservatism, and Fiscal Foolishness
So what does this have to do with agile software development? Here’s the heart of the problem. Most generally accepted accounting practices (GAAP) guidelines that apply to the accounting of software development and maintenance costs use a waterfall-style approach to development (phase-based, sequential development) to explain capitalization rules. When the finance people, then, run across an agile project, they don’t see any of the familiar milestones or triggers—meaning they don’t know how agile development fits with the GAAP capitalization guidelines. Since these folks are often by nature a fairly conservative bunch (unless you worked at Enron or Worldcom!), the safe thing for them to do with an agile project is to expense everything upfront!
This has at least two dire consequences. The first I described earlier—if you expense everything, you likely overpay on taxes and understate your company’s value. This leads to the second consequence—if waterfall projects can be capitalized (at least in some phases) and agile projects are always expensed, waterfall projects appear economically more favorable.
In “Why Should Agilists Care About Capitalization?” Dan Greening does an excellent job of laying out this issue. To summarize, when agile projects are expensed, they take an immediate cost hit. Because of their increased upfront reported cost, agile projects may then receive a lower overall development budget. Lower budgets mean fewer people or smaller salary increases. Greening gives an example of a company where agile projects are allocated half the staff that they would be given if they used waterfall development.
It is true that having more people is often not the answer to delivering better software more quickly; however, not having enough people (or having under-compensated people) is also an impediment. If I were a development manager, and I knew that I’d get half the head count for an agile project as compared to a waterfall project, I’d think hard about adopting agile. You can see, then, how a company’s reluctance to capitalize agile projects can be a major impediment to long-term success with agile development.
GAAP Guidelines Have a Waterfall Bias
Before you can start to align agile development and finance, you need to have a high-level understanding of the GAAP guidelines for when to capitalize versus when to expense in a software development environment. If you want a more comprehensive description, have a look at the Agile Alliance’s “Agile Accounting Standard Program,” directed by Pat Reed and Laszlo Szalvay, and Dan Greening’s blog posting mentioned earlier.
The following picture is a simplified summary of the guidelines. Remember, the guidelines are written with a bias towards waterfall development.
Basically, you can start capitalizing your costs when all of the following are true:
- The project has achieved technical feasibility
- You have written authorization from your management to proceed with the development
- The resources necessary for development have been committed
- Management is confident in the success of the project.
In reality, these conditions are a bit more nuanced, but they generally describe the basic triggers for when you can start capitalizing some of your costs.
I say some of your costs, because maintenance work cannot be capitalized—it must be expensed. So in the picture above, the bar chart overlaid on the waterfall model gives you a very rough idea of where costs are expensed (red bars) and where they are capitalized (green bars). Don’t read too much into the height of any one bar, the graph is intended to be indicative.
How to Do Fiscally Responsible Financial Reporting When Using Agile Development
So, now you are ready to help your colleagues on the finance team do fiscally responsible financial reporting when you use agile development! It’s a given that they are going to follow GAAP guidelines—and who can blame them? If they don’t, they risk being fired or thrown in jail. So help them understand how to apply those guidelines to an agile development effort.
The basic issue is you must be able to capture the labor costs involved in developing software (frequently yielding a long-term asset) and appropriately classify them as capitalized costs or expensed costs (operational expense).
The picture below summarizes how I have worked with different companies to address this issue. The picture itself is a modified version of Figure 9.6, “Day in the Life of a Product Owner,” from my Essential Scrum book. I refer you to Chapter 9 of that book for an in-depth description of the original picture elements.
The top part of this picture is a visual representation of the Scrum framework—everything pictured there takes place each and every sprint. Below that is a timeline that includes the first sprint of the project (shown as weeks 4 and 5), as well as the pre-work necessary before the first sprint can begin. Weeks 1 – 3 represent the work that takes place before sprint 1. Weeks 1 and 2 represent envisioning (product planning) and portfolio planning—the work necessary to determine a project’s feasibility and obtain funding approval. This time period is shaded red because, from an accounting perspective, it typically takes place before all of the conditions (triggers) stipulated by the GAAP guidelines to begin capitalization have been met. (These are the same four conditions I spelled out in the previous section)
In other words, finance folks, any work the development team does before it obtains initial funding approval should, by default, should be expensed. There could be exceptions, but hey, agile projects have a short inception period, so it won’t be a lot of time anyway. I recommend you take the conservative route and expense it all—two weeks’ worth in this example. The costs won’t typically be significant.
In this picture, week 3 (release planning) is murky—the green and the red overlap. That is because the decision to expense or capitalize the work of release planning is a judgment call. During this week agile teams are getting the product backlog ready for the first sprint (i.e., getting two to three sprints worth of product backlog items in the Ready state) and doing product backlog item size estimation so they can answer some release-planning questions (i.e., When will you be done? How many features can I get on a future date? What will this cost?). I personally think this week of work can be capitalized, but since it is only one week (as shown in this picture), if you want to be conservative, go ahead and expense it.
In this picture, weeks 4 and 5 correspond to sprint 1. They are shaded in green. At this point, you can feel comfortable capitalizing most of the costs because by this time, the following conditions have been met:
- The known elements of the project are technically feasible
- The team has authorization to proceed
- Any known, necessary resources have been committed
- Management is confident enough in the success of the project to proceed.
So, according to the GAAP guidelines, you can capitalize most of the costs—but not all of them! As with any software development effort, maintenance costs must be expensed. To help separate maintenance work from development work, you need to look at the specific items in the product backlog.
Product backlogs contain many different types of work (see my Demystifying Product Backlog Concepts blog for a more detailed description). In the picture above I show three types of product backlog items.
- Features: the work required to develop new features or make changes or enhancements to current features—can be capitalized.
- Defects: maintenance work—must be expensed.
- Knowledge-acquisition items such as prototypes, proof-of-concept, experiments, and spikes. These are necessary for achieving problem understanding or technical feasibility and should most often be expensed.
Accounting for Costs During a Sprint
Here is the good news: You do not need to track task hours in order to allocate development and maintenance costs appropriately. Instead, you can address cost allocation at a much more meaningful level—the size of each product backlog item worked on in the sprint. Many teams estimate the size of every product backlog item they bring into a sprint. These size estimates are typically expressed as points and are a very simple, reliable, and verifiable tool for doing proper cost accounting.
Let me illustrate by example. First, in most organizations the cost per sprint is a fixed cost. If you know who is on your team and you know the fixed duration of your sprint, you can very easily calculate your cost per sprint (Labor * Time = Cost per Sprint). Let’s say that cost is $20k/sprint.
Now let’s say that the team brings 40 (story) points worth of work into a sprint. If 30 points are associated with feature development, 5 points are associated with defect repair, and 5 points with knowledge acquisition, then at the end of the sprint the folks on the finance team would account for the sprint costs as follows:
Capitalize = $20k * (30/40) = $15k
Expense = $20k * (10/40) = $5k
It can be that simple! I’ve seen this approach used with companies to the satisfaction of both their internal and external auditors. It is easy to understand and apply consistently; and it requires very little effort to create accurate supporting documentation.
If your teams do not formally estimate product backlog items, you can still allocate costs. One way to do it is to define an average percent of the team’s time each sprint that is spent on new feature development vs. defects vs. knowledge acquisition. You can then use those ratios to divide up the costs. As long as your approach holds muster with your auditors, you should be good to go.
Appropriately capitalizing costs can significantly influence taxes paid and company valuation. For years, finance teams have capitalized appropriate costs associated with waterfall-style development, which is easy to do because the accounting guidelines are written from a waterfall perspective. When finance folks are unfamiliar with agile concepts, they might err on the side of being conservative, and expense all costs associated with an agile development effort. This can be fiscally foolish.
Also, when this happens, agile projects compare unfavorably with waterfall projects (parts of which will be capitalized). This inequity raises real impediments to adopting agile throughout the enterprise value chain. The good news is that once the finance folks understand agile concepts, properly accounting for costs during agile development is quite straightforward and easy to demonstrate as compliant with established accounting guidelines. To ensure fiscally responsible financial reporting when using agile development, educate everyone about key agile concepts, how they relate to GAAP guidelines, and how to properly allocate the costs for each sprint.