How to Calculate Capitalisation Costs in Scrum without Timesheets

At the London Scrum Gathering I shared a technique I use to calculate development costs for capitalisation without needing developers to track hours. I promised to blog about the technique since people found it useful. This is something I use today, in the real world. Our finance department love it, and are happy that it is auditable, and it has zero overhead on our development team. Discover the magic formula below…Firstly all our staff, including contractors have a fixed monthly salary. We don’t ask them to bill in hours, we just have an agreed rate per month. Secondly we run 2 week sprints, which align pretty closely with a month, so each month is roughly 2 sprints. Every now and again we have to split a sprint across 2 months, but not very often. In that case we just split it across 2 months. Finally our teams rotate once a month between support and development. Our teams are fixed though, so in any one month I know which people were working on support and which were working on development. Some people, like myself (Software Development Manager) work across all the teams, so effectively I am split across all the work that gets done in our teams.

Download the attached spreadsheet to see an example, and follow the steps below to fill this in for your team. Notes in square brackets tell you which block in the spreadsheet to use.

Step 1: Fill in details of everyone in Product Development. Capture their names, role, team, and salary. [Team Members]

Step 2: Note what each person was doing each month (either support, development or split) [Work Allocation]

Step 3: Figure out which of your costs are capitalisable, and what work was done in each month. For us in South Africa, we capitalise new feature work, but not support, nor technical debt or investment in our infrastructure/improvements. These rules probably differ in other countries but essentially you just have to know which is which, your finance department should be able to provide some guidelines. For us: Support is not capitalisable. For development work we look at all the stories completed in the sprint, and mark any that are new feature development as capitalisable. This is most of the work, but occasionally we do work that benefits us internally but not the product, e.g. setting up a new CI environment. Those stories are not capitalisable. We use story points to record how much work was done in a month, and record the total on capitalisable (feature work) and non capitalisable work. [Work Completed]

Step 5: Figure out the percent of capitalisable cost for people whose work is defined as Support, Dev and Split. 0% of support costs are capitalisable. Therefore for people working on support, you cannot capitalise their costs. For development the percentage of development work that is capitalisable is (story points of capitalisable work) /  (total story points). For people who are split I figure out what percentage of the team works on support, e.g. 1/3 if it is 1 out of 3 teams.  So for split people, the capitalisable amount is (development capitalisable percentage) * (1 – 1/3). [Capitalisation Percentage – This is automatically calculated in the spreadsheet]

Step 6: Fill in these percentages next to people according to the classification of work they do. [Percentage Capitalisable – This is automatically calculated in the spreadsheet]

Step 7: Multiply that person’s salary by the percentage, and it gives you the amount of their salary that is capitalisable. [Capitalisable Cost – This is automatically calculated in the spreadsheet]