Capitalization is much higher with agile techniques
The United States Financial Accounting Standards Board (FASB) outlines three general categories for determining capitalization, each falling under either the “what” or the “how” of product development:
- Preliminary (the “what”) – the activities associated with determining feasibility of a product
Feasibility is achieved when a project charter exists, which states the product is technically feasible, management has approved funding and committed resources to development, and there is confidence the product can be delivered successfully. Product vision and product roadmap are used by agile teams to approve and fund development. These are often established in a very short timeframe, usually 1-2 days, even on large projects. (OpEx)
- Preliminary (the “what”) – the activities associated with determining feasibility of a product
- Application development (the “how”) – the creation of value-added functionality
Once a product is funded, this is the implementation work by both direct and indirect laborers. Agile product development begins as early as day two, implementing one end-to-end shippable functionality requirement at a time in iterations (e.g. sprints) of no more than a month. Each requirement delivers a new channel of value for the customer (external or internal), and is elaborated, designed, developed, tested, integrated, documented and approved with product leadership before starting on the next requirement. This is repeated every iteration, incrementally releasing functionality to the customer for review and feedback, as often as daily. (CapEx)
- Application development (the “how”) – the creation of value-added functionality
- Post-implementation (the “what”) – begins once the last functionality requirement is released
Once the final product is released to the customer, it enters maintenance or operational mode. Throughout product development, whether there has been one release or 150 releases, the product is always being enhanced and exposed to the customer for gathering feedback and improving the product to meet customer needs. The Platinum Edge formula AC + OC > V is the trigger for ending product development, when the product is ready for its intended use. When the sum of actual cost and opportunity cost are greater than the value of remaining requirements, it is time to end current product development and redeploy capital on the next highest value product opportunity. (OpEx)
Each of the three FASB categories above are summarized in the following illustration.
Because agile development is driven by lightweight, high-level up-front planning (which establishes feasibility) and progressive elaboration of requirements throughout the development process, a much larger portion of costs can be capitalized. Formal phase gates as official starting points for capitalization begin much earlier (after product vision and product roadmap).
Agile CapEx Approaches
Agile teams take a fundamentally different approach to product development than traditional product development. Scrum teams progressively elaborate and prioritize their requirements using a product backlog. In the product backlog, the product owner identifies and flags each product backlog item (PBI) that can be capitalized (which should be most PBIs). Organizations may choose to take one of the following CapEx approaches—all of which are defensible.
Common
- Preliminary – product vision and product roadmap creation are OpEx (expensed)
- Application development – all inspect and adapt activities (e.g. product backlog refinement, release planning, sprint planning, daily scrum, sprint review, sprint retrospective) and artifact creation work (e.g. release plan, product backlog, sprint backlog, product increment) to the last PBI are CapEx (capitalized)
- Post-implementation – product maintenance after the last PBI is released is OpEx (expensed)
Product maintenance and defect (bug) fixes must be expensed. However, using good product development practices such as test-driven development and pair programming will significantly decrease the number of defects found in post-implementation production. Also, under an agile approach, up until the last PBI is implemented and released, product improvements based on customer feedback become new PBIs to deliver enhanced value to the customer. Although there are modifications throughout an agile development lifecycle, they are implemented as new value PBIs, and therefore can be capitalized.
Conservative
This approach is similar to “Common,” however some may argue the sprint retrospective is more process-related than product-related, and therefore choose to expense (OpEx) it. This is a very short timebox each sprint (i.e. no more than 45 minutes per week of sprint), so this does not significantly impact the amount capitalized.
Ultra-conservative
In addition to expensing the sprint retrospective, some organizations may choose to expense instead of capitalizing all of the following: product vision, product roadmap, product backlog refinement, release planning and sprint planning. Each of these are timeboxed and collectively make up a small percentage of a scrum team’s time. This approach still enables much higher CapEx than traditional approaches.
Agile CapEx Accounting
The following labor categories may be capitalizable:
- Salaries and contract labor of development team members who directly elaborate, design, develop, test, integrate, document or approve requirements for new product, new project or ongoing development to increase functionality, upgrade, revise, etc
- Product management (e.g. product owners) contributing directly to requirements definition and functionality validation associated with delivery of new value
- Indirect labor such as agile coaching (e.g. coaches, scrum masters) associated with value delivery
- Direct labor of non-scrum team members (e.g. system architects, IT operations) or others who contribute to the development of new functionality
The simplest way to track CapEx is to allocate a percentage of the sprint spent on capitalizable activities. Whether a scrum team is using relative estimating techniques (e.g. story points) or absolute estimating techniques (e.g. story hours), the calculation is similar. To illustrate using story points as a common approach, a product owner would calculate CapEx using the following formula, based on the PBIs he or she identified as CapEx in the product backlog:
- Sum the story points for all completed PBIs in the sprint that are new functionality (a)
- Sum the story points for all completed PBIs in the sprint (b)
- Divide #1 by #2, then multiply by the total sprint cost
Let us show you how to increase your CapEx using agile approaches. Coaches are available.
Disclaimer: The United States Financial Accounting Standards Board (FASB) outlines what is appropriate for capitalizing and operationalizing expenses for internal software products in Accounting Standards Codification (ASC) Topic 350 and Statement of Position (SOP) 98-1, and for software products for sale under ASC 985 and Financial Account Standards (FAS) 86. You should seek financial and accounting advice from accounting professionals. This document is only a summary and commentary on how the standards have been or might be applied using agile product development approaches. Platinum Edge expressly disclaims any guarantee of accuracy.
