Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jul 10, 2008 — Enterprise Agile Planning expert

Capitalization of Sprint Activities

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

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us