Capitalization of Sprint Activities

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).

Jim

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

Download the PDF version: Capitalization of Sprint Activities blog