Agile Capitalization

Why Should Agilists Care About Capitalization?

Dan R Greening, PhD. Managing Director, Senex Rex

In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. I claim Scrum teams create production cost data that are more verifiable, better documented, and more closely aligned with known customer value than most waterfall implementations. Better reporting can mean significant tax savings and greater investor interest. Agile companies should change their financial reporting practices to exploit Scrum’s advantages. It might not be easy, but I did it.

Scrum’s production experiment framework aligns perfectly with the principles of financial reporting.

When I restructured software capitalization according to the principles here during an all-company Scrum transition at a 900-person software company, we delighted auditors, gave more insight to upper management and raised more internal money to hire developers. We gained millions in tax savings, by using Scrum Product Backlog Items to more accurately document and capitalize our software work.

I hope to arm you with perspectives and resources to make the accounting argument for agile capitalization, potentially reducing your company’s tax burden, increasing available funds for engineers, and making your auditors happy.

Senex Rex offers an Agile Capitalization Workshop, to help companies apply these techniques to their specific circumstances. See Agile Capitalization Workshop for more details.

Software is a Capital Investment

Software development is an investment in the long-term future. We spend money up-front on engineer salaries and then (hopefully) profit later from cost-savings or revenue. If we invest wisely—converting cash (one type of asset) into software (another type of asset)—the company’s value should go up. Tax authorities and investors rely on financial reports to understand the value of a company. How we report development expenses matters.

First, let’s define capitalization and expensing. “Capitalization” means spreading investment costs (sometimes called “capital investments” or “capital expenses”) over a long-term asset’s life of returning value. Capitalization is used in tax filings and financial reports (such as Profit & Loss Reports). Capital investments become part of the declared assets of the company. “Expensing” means “taking the hit” of a cost immediately, as an “operational expense” that returns short-term or no value. A company that expenses all of its software development has a hard time arguing that its software is part of its long-term value.

Some software development projects are not long-term investments; it depends on whether the software remains an asset. For example, a software contracting shop that builds and sells custom software while retaining no ongoing rights cannot capitalize it (but the purchasing company might be able to).

It’s easy to make damaging mistakes when classifying software costs. Some companies incorrectly treat all software investment as an operational expense, which hides its true value. Although this mistake could provide an opportunity for impropriety, classifying software investments as operational expense usually just results in the company overpaying taxes and understating its value; this would depress its stock price and reduce its borrowing power.

Agilists Should Understand Capitalization

If finance people treat Scrum product development incorrectly, their policies could insidiously erode support for Scrum. Agile has confused some financial professionals who conclude agile software is somehow “temporary” due to its frequent release cadence.

I know one company that treats the same type of software product as an operational expense if developed with agile processes and as a capital investment if developed with waterfall processes, and then cuts software budgets in half for agile projects!

Agilists should learn proper capitalization and teach their colleagues. Misunderstandings in how to track and report agile project costs have cost many companies millions of dollars in improper taxation. Poor capitalization rules create choppy income statements for agile companies, making them look poorly managed. So-called “conservative” waterfall processes can rarely track which design efforts or management tasks led to which features, while agile methods can. Yet accountants typically do not understand how to properly track and report labor in agile projects.

Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development. If they capitalize properly, they report their finances more responsibly to shareholders and regulators. To properly capitalize, we must capture labor costs involved in creating the asset and appropriately classify those costs as “capitalized” or “expensed”.

Product Backlog Items, which explain the value delivered to a stakeholder, can be easily classified. But waterfall—with its endless design period and confused phases (check out a RUP phase diagram, you will see muddiness everywhere)—rarely can track which design efforts or project management tasks led to which features. One would think that finance people and tax authorities would love agile practices.

But most finance experts and technical accountants do not have a deep understanding of agile practices. Accounting standards use waterfall examples to explain capitalization principles. Misapplied waterfall language can lead people to misclassify software development. Corporate agilists need to help finance departments capitalize agile software development properly; otherwise the company could suffer excessive tax liability and engineering staff cuts; and expose themselves to the risk of audit exception findings and subsequent re-reporting of earnings.

Misunderstandings of agile capitalization principles have led to dramatic staff cuts. Pat Reed (another agile enterprise consultant) and I recently discussed capitalization with a manager at a huge engineering company. This manager told us his finance department capitalizes waterfall development normally, but treats agile development as an “operational expense,” because finance asserted (incorrectly) that all Sprints are effectively “Preliminary Project Stage” work. I asked, “So does this limit your headcount?” He admitted, “Yes, any department that choses to use agile practices expects its headcount to be halved.”

On the positive side, ScrumMasters and agile department heads who understand capitalization can generate millions in tax savings, because good agile practices can enable more verifiable capitalization and because spreading investment costs over time often reduces the overall tax and helps find earlier funding to hire additional engineers. Here’s why ScrumMasters have this power:

  1. ScrumMasters, often more than anyone else in the company, can correctly classify work as long-term investment or short-term expense, and usually have all the data needed to defend their classifications with financial staff and external auditors.
  2. ScrumMasters promote processes that align actual team behavior with documented goals more reliably. Scrum techniques have an adaptive statistical basis, backed by experimentation, which is absent in classic project management techniques. In my experience, auditors can trust agile-based reporting more than waterfall-based “actuals”.

If, as a ScrumMaster, you want to tackle this opportunity, labor classification will then likely become your responsibility along with other ScrumMasters in the company. You will likely become, by necessity, an expert on the topics of software capitalization, depreciation and impairment. Welcome to the world of finance!

Proper classification Creates a Bright Future

Tax authorities and investors use operational expense and capital expense concepts to make better decisions. They usually want companies to invest in the long term, so they let companies spread investment costs over time to offset revenues roughly in parallel as the investment earns money.

Software work can provide short-term value (all ROI in under a year) or long-term value (ROI over a multi-year period). Here’s a short-term example: a contract software company might create a web site for a customer, get paid for it and retain no further rights. In this case, we say development cost is an “operational expense” (opex).

Public companies usually must report yearly and quarterly profit to shareholders and tax authorities. Computing the profit seems easy:

profit = revenue – expense

Here’s a long-term example: a toy retailer builds a web site to sells its toys. Years after it built the web site, the long-completed work keeps generating revenue. In this case, we say development cost is “capital expense,” a long-term investment. Computing the total profit, ex post facto, is easy:

total_profit = revenue(year_1) + … + revenue(year_n) – investment

Every year shareholders and tax authorities expect a financial report: their first concern might be to ask “What were our profits last year? If we have a long-term software project that gains no revenue in its first year, and if we have to treat it as an operational expense, we might need to post a loss. Fearful shareholders might sell shares of our company! Maybe we don’t have to pay taxes this year; great! But next year we might have no development expense and a lot of revenues from our toy retail site, in some jurisdictions taxed in full!” If we had to treat development efforts this way, it would discourage us from investing long-term.

Wisely, tax authorities and accounting groups let us spread these capital expenses over time using a system called “depreciation.” Most depreciation schedules spread a capital expense evenly over the expected lifetime of the software;if the toy retail site we develop will likely stay in use over a 5 year period, we can expense 20% of the development cost the first year after deployment and 20% each year after through the 5th year. (Contact an accountant for more information on depreciation schedules, which can vary depending on the expected lifetime of an asset.)

An investment might not be usable immediately. Since we don’t immediately gain revenue from it, we can usually defer depreciation until it goes into use. The accounting shorthand for this time before deployment is the “capitalization period.” (Capitalization benefits continue after depreciation starts, by the way.) If we remove features in our web site software or stop using it entirely (possibly because we replaced it) either before or after deployment, we “impair” our old investment and then have to immediately expense all remaining costs.

Companies can gain tax advantages by capitalizing software development: by deferring costs they typically offset more taxable revenue and gain more interest income. Departments also gain some advantages in hiring. When a department can defer software investment costs it often can spend that deferred cost on employee salaries (hiring more people, provide raises, etc.)

Profit and Loss with and without depreciation

The graph illustrates how profit and loss (P&L) can be affected by depreciation. The numbers shown are in thousands of dollars. As is typical for software projects, the major costs (Dev Cost) occur at the beginning of the project: $2 million in 2012 and $2 million in 2013. In 2014 and beyond, the costs will be $200,000 per year which is the cost of adding features to the software. The project doesn’t start earning revenue or cost-savings until it is deployed in 2014, and at that point it may earn $1.2 million yearly.

If project costs are not depreciated but expensed immediately, the blue line tells the P&L story: Huge losses in the first two years, then enormous profits in subsequent years.

When costs are depreciated, the green line tells a different P&L story. No costs are taken from P&L until the software is put into use. When the software is placed in use, we compute our profit by depreciating the cost over a five-year window.

Why is this important? Governments typically tax P&L on positive amounts, and make it difficult to use losses to reduce future year taxable P&L (unless you can justify your choice with depreciation.)

Finance people often over-expense by treating all software expenses as operational expenses, claiming this is somehow conservative behavior. It isn’t. If you are investing in the long-term, placing software investments in a short-term expense class will make your company look volatile—that’s irresponsible to your shareholders. It can generate higher tax liability, which is both irresponsible to your company and out-of-line with the goals of your host country, which would want you to invest long-term.

A company with high profits can offset a product development department’s production losses. This would avoid the tax problem, but it doesn’t avoid the poor-planning problem. In my experience, executives pay attention to departmental profits and losses and drive headcount from that. Who among us have not seen boom-and-bust cycles of hiring and firing in large software concerns? In part, this headcount volatility is caused by failure to properly recognize software as an investment.

Finally, if agile software projects are expensed and waterfall projects are not, it would essentially doom any long-term enterprise adoption of agile practices. If waterfall projects can hire more employees but agile projects can’t, guess what methodology managers will promote?

Recommended Accounting Practices Ignore Agile

Accounting practices are not completely dictated by tax and securities law. Instead, the US Financial Accounting Standards Board (FASB) interprets these laws to produce “generally accepted accounting practices” (GAAP). FASB guidelines for internal use software are in [ASC 350-40], and for externally sold software are in [ASC 985-20]. Their treatments are roughly equivalent for this discussion. The International Accounting Standards Board (IASB) produces the “International Financial Reporting Standards” (IFRS). FASB and IASB provide guidance on how to interpret law. Their recommendations, written before agile practices were popular, show how to classify work using waterfall examples.

Waterfall Capitalization Timeline

Misinformed people believe FASB and IASB guidelines force agile projects into a waterfall world of engineer time tracking, with RUP-like phases of analysis, prototyping, development, packaging and maintenance. Instead, the guidelines state that market analysis prior to development is expensed, prototyping prior to a decision to invest is expensed, development for long-term value is capitalized, packaging for shipment is capitalized, and maintenance (fixing bugs) is expensed. The figure above shows capitalized items in green.

Auditors recognize that FASB and IASB guidance cannot be routinely applied to new situations. What tax authorities and auditors look for is conformance to law and its spirit, consistent application, and full transparency. We can give them all that; but because agile practice is new, we must understand the law and its motivations, document our capitalization policies and practices, track project work consistently and be perfectly transparent. This aligns well with agile principles.

However, if you ignore the law and its motivations, inconsistently track work or fail to document processes clearly, you risk the wrath of tax authorities and investors. Adverse audit findings and the resulting submission of corrected financial reports can cause tax authorities and investors to lose trust in the company, which would subject it to higher scrutiny and a lower stock price.

If you are interested in the basis of FASB guidelines and you are in the United States, refer to US Tax Codes [26 USC 167] [26 USC 197] [26 USC 179]. It turns out that most countries operate the same way for this topic.

Finance departments are justifiably conservative in their approach. If your finance department doesn’t like how you do things, they could:

  • Force engineers to track hours (degrading their creativity and productivity with mind-numbing work-tracking),
  • Undercapitalize software development (leaving huge sums on the table), or
  • Reclassify past expenses (raising investor questions about the stability of the company).

It’s easy to make multi-million dollar mistakes in this area. Because the vast majority of companies make capitalization mistakes that increase tax receipts, the authorities don’t complain. Because agile software practices are arcane to investors, they don’t complain either. But they should.

If you involve at least one person that has a moderately good understanding of three fields—finance, engineering and process—you can dramatically improve your bottom line. Since the returns are so high, it may be worthwhile to hire a consultant to help get it right.

How to: Financial Reporting in the Agile Frontier

Until FASB and IASB guidelines are revised to explicitly discuss agile examples, responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.

First, establish a clear and consistent bright line demarking when your company could start capitalizing work. ASC 350-40 states cost capitalization can begin when all work in the “Preliminary Project Phase” is complete when management commits to funding it, and when “it is probable that the project will be completed … and used. Capitalization begins when you move from “what” to “how” you will design and develop the software asset.”

In most cases, capitalization should begin when the whole production team assembles for its first sprint. Your company should complete an initial market exploration and architectural design before it invests in a full team of designers, engineers and testers. However, if a research team runs a “feasibility spike” sprint to determine which architecture to use or whether the market warrants further sprints before it can create something that could provide long-term value, you are likely in a “Preliminary Project Phase,” and your costs should be treated as operational expenses.

Once your company has committed funding to a project likely to be completed and used you can start capitalizing the work. All work critical to designing, creating, testing and deploying the asset should be capitalized, including engineers, testers, user experience designers, product management, project management and ScrumMasters.

Second, establish whether the entire or only part of the project should be capitalized. In many cases after the “Preliminary Project Phase” the entire project cost can be capitalized. This happens when a significant percentage of the work (we felt 95% was sufficient) should be classified as capital expense. However, some common activities must be expensed.

If any of the following apply to you, you may have a mixed-mode project:

  • Your team is fixing regression bugs in a released product while developing new features.
  • Your team is creating a product for international release, and is localizing the product for multiple languages.
  • Your team (not just its software) manually converts data from one form to another.
  • Your team helps train people to use the software.
  • Your team participates in operations activities beyond deployment, such as monitoring, reporting, backup, machine configuration.
  • Your team performs routine Sarbanes-Oxley (SOX) or security reviews [15 USC 7211].
  • Your team refactors code unlikely to be relevant to new functionality (you probably shouldn’t do this anyway.)
  • Your team modifies software to support individual customers.

Whether these items or others should be expensed or capitalized will depend on your finance department and technical accounting advisors.

How to: Classify Mixed-Mode Projects

If you have mixed-mode projects, establish a way to apportion labor to operational or capital expenses. If you have strong Scrum practices within your organization, you can likely defensibly use proportional allocation of estimation points (also called “story points”) for each team. If each team has a different point-scale, it can be accommodated. For a quarter, sum the points completed by the team then divide it by the total cost of the team (including product owner, ScrumMaster, team members and the appropriate percentage of part-time contributor salaries). You will now have the “cost per point.”

IDDescriptionEstimateCap?
1Add international language capability8Y
2Fix regression bug in English-language version5N
3Localize for Spain, France, Germany13N
4Customize software for Acme Corp client3N
5Restructure site with better graphics, information flow13Y
6Fix bug that “export” never worked on Mac OS X8Y
7Implement import function13Y

In this example, the team completed 63 estimation points in its 4 week Sprint. 42 points were capitalizable. If the total team cost (the total salaries for the team) for those 4 weeks was $112,000, then the capital expense was $112,000 × (42 ÷ 63) = $75,000.

If product owners write Product Backlog Items in a ritualized story form it can be easier to determine whether it is a capital or operational expense. My preferred PBI story form, a variation of a form promoted by Chris Matts and Dan North [North 2006], helps clarify most classification work. It looks like this:

As a <stakeholder>,
I can <perform an action>,
so our company <receives business value>

Acceptance tests:

  • <acceptance test 1>
  • <acceptance test 2>
  • …

In this format, you substitute specific values for <stakeholder>, <perform an action>, <receives business value>and <acceptance test …>. The stakeholders are never the team, but they can be anyone else consuming the product: a user, a customer, a systems operator, a business analyst, or an administrator. If you aren’t serving someone outside the team, it isn’t really a “user story.” should be something that the stakeholder can do that they couldn’t do before the Product Backlog Item was completed. is a phrase usually articulated with the developing company in mind: Why are we building this? Will we get more users? Will users pay more for the product? We will gain a competitive edge or match a competitor’s features? Will we save operations costs? On rare occasions, the can be a future developer; this accounts for focused efforts to reduce technical debt, however; make sure the acceptance tests confirm that future developers benefit.

Finally, we have acceptance tests. I counsel teams that acceptance tests should be written so stakeholders (usually non developers) can verify that the work was done, ideally in the Sprint Review. An acceptance test written for a team member to verify is not really an acceptance test.

Here’s an example:

As a systems operator,
I can monitor the current load on the system,
so the company can add machines if the load approaches the point where new users will be denied access.

Acceptance tests:

  • From the administration screen, a systems operator can easily find the load.
  • If the load is in the green area, at least 50% more users can be added to the system without concern. If the load is in the yellow area, at least 20% more users can be added to the system without concern.
  • When the load is in the red area, additional machines can be added to bring the load back to the yellow or green region.

This story should be capitalized, because it adds functionality not previously available even though it serves a stakeholder inside the company. This subtlety is sometimes missed, but is clear from thoughtful reading of [ASC 350-40], which contains the concept in its title “Internal Use Software.” Because most cloud computing and web site development projects run in the developer company’s machines, they are characterized as internal use software.

This format not only serves well for financial classification, but also has benefits in helping the team understand the context of its work.

What about tracking hours?

Whenever capitalization comes up, someone usually suggests that one “just track programmer hours.” This is a mistake, not only because it disrupts agile behavior, but also because measurement is likely inaccurate and not as verifiable.

Hour-by-hour financial monitoring slows down software development. Software development is creative work, and interruptions to track hours disturb the creative process. If we enforced hour-by-hour tracking with engineers, we would pull developers from their Zen state of thinking about the stakeholder, stakeholder actions, the acceptance tests and the code into a self-conscious state of thinking about what they did in the last hour.

So, to avoid the disruption, companies almost always simply ask engineers to fill out time cards at the end of the week, at best. By this time, the work they’ve done is lost in the fog of the past. In my experience, their weekly reporting is quite inaccurate.

Auditors support accounting practices that provide honest transparency while maintaining high productivity. Those auditors I’ve encountered acknowledge that hour-by-hour tracking is problematic. When I have suggested that proportionally allocating actual cost by story points would provide honest transparency, they have, at first, cautiously agreed.

In doing so, I make an assertion that “estimated effort” is highly correlated with actual work time. This assertion is defensible. The Scrum framework is designed to help teams drive toward high correlation between estimation points and actual time. Scrum provides better forecasting accuracy than waterfall, and teams that embrace Scrum principles examine their estimation points and outcomes, trying to ensure that their sprint forecasts are roughly met by the sprint result.

Auditors become enthusiastic supporters of this approach when they see the effect. When we track PBIs, estimation points and completion dates (sprint end dates), we know exactly which team did the work, we usually have a day-by-day task burndown and we have a proportional allocation. The PBIs we report are well documented and understandable (thanks to the story form). When auditors visit team members, the team members say the same thing executives say. This is an auditors dream: that managers and executives report aggregate data verifiably backed by statements from individual contributors.

What happens in a transition to agile capitalization?

If you are about to embark on a transition from waterfall to Scrum, this is a great opportunity to consider changes in financial reporting. Agile approaches to software development are radically different from waterfall, and so justify a significant change in financial reporting methodology.

First, you can create a nearly bulletproof system for tracking engineering costs that eliminates the need to track actual hours. Auditors and financial staff will at first be wary with this new approach, then delighted when they realize that everyone—from developers to ScrumMasters to Product Owners to managers to finance staff—discuss the work your company does consistently and thoughtfully.

You may find that transitioning to a more accurate and responsible capitalization approach dramatically increases the amount of work capitalized. Your finance department should expect a high rate of capitalization, because the work of software development is usually an investment in a long-term future. However, a dramatic change can be seen as a red flag to them and their auditors.

You should address these concerns head-on. Explain that agile software practices make this detailed approach feasible. It can be difficult for waterfall teams to responsibly track which design efforts or project management tasks led to which features, while agile methods will expose this information naturally through sprint backlogs. So, for example, in the past your company might have lumped post-investment-decision design work into the “Preliminary Project Phase.” This would no longer be appropriate.

Furthermore, because agile practices create releasable software every month, they can tie infrastructure development work with individual features, making those efforts capitalizable. Some waterfall companies have felt that infrastructure work was so indirectly connected with user features that it had to be expensed.

Regardless of your situation, be completely frank with finance and auditors. If you expect your capitalization rate to increase dramatically, share that information with them. Discuss why this will happen. And finally, explicitly connect these changes to your company’s transition to agile. Your commentary may actually appear in a company shareholder report, which you should welcome; proud agilist that you are.

Summary

If you have read this far, you are likely an enterprise agilist; comfortable with the idea that agile thinking should affect not just engineering, but also finance and other departments. Welcome!

Now that you know more about agile capitalization, your company has an opportunity to report its activities more responsibly to shareholders and tax authorities. This can require a lot of negotiation, planning and process changes to do so. However, your engineering group may be able to hire more engineers, your company may be able to reduce its tax burden significantly and your company’s financial reports may stabilize. The value of these improvements may be in the millions.

For agility and the greater good, I remain your humble servant.

Author

Daniel R Greening, Ph.D. is Managing Director of Senex Rex, a management consultancy operating in the US and Europe. He designed and implemented the capitalization strategy used at Citrix Online and advises companies on this topic. Dan leads enterprises in sustainable agile transformations. He is currently Product Owner for agile coaching internationally at one of his clients, a large software company. Dan previously led all-engineering process transformations at Citrix Online and Overstock.com. He can be reached at [email protected].

Acknowledgements

Thanks to Dr. Mark Lane, Pat Reed, Walt Wycoff, David Starr, Erik Gibson and Vince Mills for their editorial help. Thanks to Citrix Online for its permission to share this information.

This article was originally posted as Why Should Agilists Care about Capitalization in InfoQ on January 29, 2013.

References