Capitalization of IT Labor at Valpak

Been meaning to write this post for quite some time.  It’s not the most thrilling of agile topics so my procrastinator has been hard at work.

Let’s talk about the capitalization of IT labor!  Woo hoo!

Some of you may recall, if you’ve been following along, that Valpak was acquired by a private equity firm in January of this year.  With that came many changes including the direction from our new owners to capitalize on certain large IT projects (Valpak was previously owned by Cox Media Group which neither required nor encouraged such things).  Initially, this lead to a panic among us leaders.  How can we be agile while having to account for every minute of our time? 

After the initial panic subsided and we started doing some research, we found that there are very agile ways of handling IT labor capitalization.  In fact, we learned that there is no one right way to meet the GAAP standard.  There was hope for us after all!

Before I get down to the nitty-gritty business of capitalization, I’d like to share with you a few resources I found helpful along the way.

• A super insightful blog post by Catherine Connor of 101 Ways on The Top 10 Pitfalls of Agile Capitalization
• Very handy documentation from the Scaled Agile Framework (SAFe) folks on CapEx and OpEx with some great illustrations for understanding the concepts and options.
• Last but not least, Pat Reed’s work on the Agile Accounting initiative as part of the Agile Alliance provides a great overview.  The Citrix case study is helpful too, but be be warned that if you contact the person that wrote it they will want to charge you $400/hour to answer your questions.

Now, let’s get down to it … I won’t bore you with the various permutations we attempted over the first few months (there was some pain involved).  Rather, I’ll jump to the good stuff … I have for you our IT Capitalization Policy as documented by myself and approved by our Accounting department and our auditors.

IT Capitalization Policy at Valpak

The following documents the policy for capitalizing software development costs at Valpak.  Not all projects will be capitalized.  Only certain large IT projects will be capitalized.  Projects to be capitalized will be identified each year as part of the budget process.

All software development work to be capitalized will be identified at the story level.  Stories to be capitalized will be flagged in Target Process as CapEx by the Agile Project Leader as part of the team’s process.  Budgeted projects will be capitalized using one of two methods, either by story count or actual hours.  Scrum teams will use the story count method.  Kanban teams will choose either story count or actual hours based on what is most accurate for their process.  The method applied will be consistent for any given team.  The Agile Project Leaders will maintain detailed calculations for all their teams and ensure auditability of data in Target Process.

For the story count method, stories are counted by the month in which they are completed (not necessarily released) in order to determine the percent of stories completed that are CapEx for any given team.  The CapEx percent is then applied to the number of available work hours in a given month to determine how many of those work hours are to be capitalized.  In addition, shared resources are taken into account and available work hours reduced by PTO.

In some special cases where a person on a team is solely focused on certain stories (not contributing to all of the stories in a given month), it may be more accurate to apply the story count method at the individual person level rather than the team level.   For instance, Team A completes 1 of 20 CapEx stories and that one story was the sole focus of a single person for 100% of their available work hours.  In such cases, the Agile Project Leader will determine the more accurate level at which to apply the story count method, team or person, and calculate accordingly.  Where person-level story count is applied, it will be notated in the detailed spreadsheets.

Here are several examples of the story count method applied:

• A person dedicated to a single team who has worked every day in January (no PTO taken).  Their team completes 17 CapEx out of 20 stories in January or 85%.  There are 20 work days in January for a total of 160 hours.  This equates to 136 CapEx hours for this person.
• A person dedicated to a single team who took a week off in January.  Their team completes 17 CapEx out of 20 stories in January or 85%.  There are 20 work days in January for a total of 160 hours but they took 40 of them as PTO for a subtotal of 120 hours.  This equates to 102 CapEx hours for this person.
• A person split (shared) 50% between two teams in January.  Team A completes 17 CapEx out of 20 stories in January or 85%.  Team B completes 10 CapEx out of 15 stories in January or 67%.  There are 20 work days in January for a total of 160 hours.  This equates to 68 CapEx hours for this person for Team A (160 hrs x 50% x 85%) and 53.6 CapEx hours for this person for Team B (160 hrs x 50% x 67%).  If this split person took PTO, it would be taken out of the monthly available hours first.

The actual hours method may be applied by Kanban teams where it is determined to be the more accurate approach for their process.  Actual hours will be recorded by each team member for CapEx stories in Target Process.  The Agile Project Leaders will collect and report the actual CapEx hours for all team members each month.

For project leadership roles like Agile Project Leaders, a projected allocation will be applied each month to their available work hours.