Here is another in my occasional series on the finer points of scrum. See also Sprint Planning with Time Separation. Cost accounting seems inimical to scrum, philosophically, and also infeasible. We use story points for a reason, and then we let the team discover its velocity through experience. Neither of these numbers is readily convertible into dollars, but that’s exactly what we’re going to do.
If the latest sprint delivered 70 story points, those points are worth $402 each.
Our goal is to calculate how much was spent to develop a certain feature. This can be to support a cost-benefit analysis, to track development as a capital investment, or to claim an R&D tax credit.
The team’s velocity is the number of story points it can complete in one sprint, typically two weeks. Velocity changes from one sprint to the next, but the key is – we know the velocity of the most-recent sprint, and that’s the one we need to account for.
We also know how much it costs to run a sprint. Let’s say that we have a seven-person scrum team with an aggregate base salary of $677,500. Adding an 8% burden rate and dividing by 26, we calculate that the cost per sprint is $28,142.
So, if the latest sprint delivered 70 story points, those points are worth $402 each. Now, let’s say that two capital projects absorbed 65 of the 70 points, plus a stray five-point story that fixed a bug or something. It was a regular expense. Here is the cost allocation:
It’s easy enough for the scrum master to load these figures into an accounting system at the end of each sprint, but it does require each user story to be tagged with the project it represents. If you’re using Jira, it’s best to group the stories into epics, which represent new features, and include the capital project identifier (i.e., an account number) on the epic.
Virag Consulting 