For most organizations, agile is confined to technology development and delivery - but it should not be. As the agile industry matures, innovative companies are taking advantage of the same agile values, principles, and practices that have transformed software development. Now, they are successfully deploying this way-of-work in other business units, from marketing to human resources to finance. When companies implement agile across their entire organization, ways of working improves dramatically. Agile methods are more collaborative, creative, effective, and can be more efficient than other business models. These agile methods such as Scrum, Scrumban, and Kanban are embraced in the Agile Axiom Framework. But companies must first understand why their current business structures needs to change.


Companies can sometimes make the budgeting and forecasting process more difficult than it already is by accepting their laborious, tedious and often frustrating manual processes as status quo. Technology teams have spent decades evolving the way software is developed, and today largely apply principles of agile development methodology to quickly complete critical releases, and generally operate more efficiently. The success of agile approaches by IT teams has led other departments to borrow these methods to make their own teams more nimble. Finance teams, which commonly rely on cumbersome spreadsheet templates, email and intranet-based processes – not to mention long delivery cycles – can perhaps benefit the most from applying agile approaches to planning technology investments.

Companies that have agile Technology budgeting and forecasting processes will have the competitive edge when it comes to quickly responding to changing business needs and market dynamics. Achieving new levels of agility requires new ways of thinking about Technology budgeting and forecasting and new approaches to these critical processes. So consider taking a moment to evaluate how you can apply some of these concepts to become more efficient and productive. (Review Agile VS & Budget, and Agile Contracts form the A2F Framework for more details on Agile budgeting).


Per accounting regulations, project expenses are divided into two taxable categories: operating expense, and capital expense. Operating expenses are those ongoing costs related to running the business, such as administrative personnel, rent, supplies and maintenance, training, sales and marketing. Capital expense are those expenses related to investment in expanding the business somehow, and in a research and development-type business enterprise, projects incur both types of expenses.

Capitalization is allowable at the point at which the project becomes technically feasible, management has provided written approval to fund development and committed necessary resources, and expressed confidence that the product will be successfully produced and delivered. While this clears dividing line is compatible with a waterfall, or sequenced type development which demonstrates a clear shift in project focus (usually a key approval) that satisfies the criteria for capitalization.

Agile program portfolios can base their capitalization on value streams and agile program portfolios; program authorities select projects for capitalization from a Kanban backlog and set them in motion. From there on out, the effort to produce a feature or product must be accounted for, in order to be identified for potential capitalization.

There are three basic ways to capture and account for the work related to feature development: recording actual time spent, by using story point estimates for each task or contributing line of work, and by using story count estimates for each completed program portfolio timebox.

Using actual time spent is a good way to be precise when calculating capital expenses, but it also reduces the speed of delivery and such precision is not usually necessary. Using actual time spent might be a good way to establish baselines upon which to create estimates for future use however, in order to estimate the "story point" value for each effort. Story points are increments of work that define value in a relative way, enabling one to calculate capitalized efforts as a percentage of overall, without bogging down into the details of actual times spent. However, in some Agile program portfolios, there may be literally hundreds of tasks or lines of work meaning that it is a great deal of work to capture even a moderate level of detail for capitalization treatment. At this scale, it may be as effective to simply count the number of capitalization-eligible tasks, lines of work, or "stories" required to complete the project in order to make a calculation of the percentage of efforts eligible for capitalization treatment. This approach is subject to occasional audit to ensure sufficient accuracy, but does allow the team to focus their efforts on tasks that deliver value.

Generally, capitalization is indicated for those expenses (including labor and subcontractor expenses) related to the implementation of a specific product (or improvement of an existing product). This includes designers, developers, subject matter experts, testers and other team members involved in refining and implementing projects. Other team members, such as Product Owners and Scrum Masters, are also directly involved in implementation and value delivery, possibly making some of their efforts appropriate for capitalization as well.