Last Updated Jul 10, 2008 — Enterprise Agile Planning expert
Enterprise Agile Planning

Capitalization of a software project is extremely important to organizations engaged primarily in application development these days. To put it simply, the US government allows a company to defer the taxes that would normally be paid on research and development activities until such time as the product is generally available and the company can begin selling the product and bringing in revenue. At that point, the company (who has to have carefully tracked all of that R&D time) must begin paying the deferred taxes over a period of a few years (usually about five years). But how do we collect this information from a Scrum team?

Unfortunately, this has led organizations to put a significant focus on how “good” a Scrum team’s estimates are, in order to use those estimates to determined the capitalized hours for the Sprint. However, capitalization need not be done in advance (i.e., using the estimates from Sprint Planning). I recommend providing a time tracking tool in which each developer records their time spent working on a capitalizable story or task. This could be a very simple tool — in fact, I recommend keeping it simple…that’s what ensures that it gets done. Use your task cards to collect actual hours too (ScrumWorks does this as well).

At the same time, however, you can make this even simpler if you choose. The calculation of capitalization doesn’t care which task you are working on at what point. Therefore, for any given Sprint, you really only need two or three activities against which your developers should be tracking their time: 1) capitalizable development, 2) non-capitalizable activities (meetings, training, etc), and 3) support. The real challenge here will be getting everyone to understand which work they do goes in activity #1 and which go into activity #2.

Organizations that require estimates to be very close to actuals for the purposes of determining capitalization are deliberately creating a dangerous dysfunction that will result in padded estimates and failed Sprint Planning meetings. They may also be breaking the law; capitalization should be done on actual actuals. Not on the original estimates.

As with everything else in agile development – keep it simple. Capitalization sounds complicated and, from the accounting end, it is. From the Scrum team perspective, it’s very simple. How many hours did I spend on this task or on R&D today. Write it down. Add it up at the end of the Sprint. Done. In fact, make it part of your DONEness criteria if you need to (that’s the easiest way to introduce regulatory controls into a Sprint).


(Additional thoughts from others with experiences related to capitalization are VERY welcome!!!!)

Download the PDF version: Capitalization of Sprint Activities blog

Are you ready to scale your enterprise?


What's New In The World of

May 19, 2023

What is SAFe PI Planning?

PI Planning aims to bring together all the people doing the work and empower them to plan, estimate, innovate, and commit to work that aligns with the business’s high-level goals, vision, and strategy.

Learn More
July 5, 2022

How to bring external data to Agility

Silvia Davis, Sr. Product Marketing Manager at, tells her story of how a positive app experience led to the realization that proper data integration is essential to the entire application lifecycle.
Key points:  
– Product managers, portfolio managers, and scrum masters need visibility in the entire application lifecycle to avoid risks of application delivery delays.  
– Integration between Agility and other application development tools is an essential element in getting visibility within the whole application lifecycle.  
– Agility has out-of-the-box connectors to other application development tools via marketplace, and an API, allowing customers and partners to quickly create integrations with their own application’s ecosystem. 

Learn More
April 19, 2022

Happy Anniversary!

This year, turns two! Continue reading for insight on’s journey and what plans we have for the future.

Learn More