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

Posted in Agile
2 comments on “Capitalization of Sprint Activities
  1. Michael James says:

    As Jim mentions, ScrumWorks Pro supports this. Despite our concern that detailed time tracking would be abused (comparing estimates to actuals, etc.), we added the capability a couple years ago to help support organizations that needed it for tax purposes.

    To turn this on, go to “File -> Product Properties” and enable “Timesheets.”

    –mj

  2. Laszlo Szalvay says:

    Hey Jim,
    I have been thinking about this problem for quite some time, ever since I met with our own CPA firm to discuss it. The issue is around what qualifies as an R+D credit. Relying on Product Owners, Team Members or ScrumMasters to interpret FASB rulings that are geared towards phased-based software development models is really hairy. One of the rules, for example is ‘technical feasibility’ — what does that mean in a Scrum environment? I think it means something very different than a waterfall based approach.

    Here’s a <a href=”http://danube.com/blog/laszloszalvay/an_alternative_approach_to_tracking_research_and_development_tax_credits_utilizing_scrumworks_pro”blog I wrote a few weeks ago on this topic where I encourage teams to use themes, web reports and PBIs in ScrumWorks and collect data at the PBI level because I thought it was similar in spirit to the Scrum framework.

    Although this isn’t something that has been approved by FASB, it demonstrates to me how many different layers of an enterprise Scrum hits.

    just my 2 cents.
    Laszlo

Leave a Reply

Your email address will not be published. Required fields are marked *

*