Loading…
Loading…
Engineering plans in sprints and finance reports in months. Here is how to derive a defensible cost allocation without asking engineers to fill in timesheets.
Engineering runs in two week sprints. Finance reports in calendar months. Those two rhythms do not line up, and the gap between them is where most engineering cost allocation quietly becomes guesswork.
The usual fix is timesheets. Engineers are asked to record how their week split across projects, and finance uses the result. It works on paper. In practice it produces low-fidelity data at a high cost in goodwill, because the person filling in the form is reconstructing last week from memory at 5pm on a Friday.
There is a better source, and your engineering organisation is already producing it.
A team running sprints generates a continuous record of what it worked on. Not as a report anyone writes, but as a side effect of how the work is managed:
That is an activity record. It is more granular than a timesheet, it was created at the moment the work happened rather than remembered afterwards, and nobody had to be asked for it.
Two mechanics need settling before any of this produces a number finance can use.
Sprints straddle month ends. A sprint running 24 June to 7 July belongs partly to each month. Pick one convention and apply it every period. Splitting on calendar days is the simplest and it is what most teams land on: a 10 working day sprint with 5 days in June contributes half its effort to June.
The important part is not which convention you choose. It is that the convention is written down and applied by a rule rather than decided fresh each month. A convention applied consistently is explainable. A convention chosen per period is not.
Carryover needs a rule too. A ticket committed in one sprint and finished two sprints later has consumed effort in each. Attributing all of it to the sprint where it closed distorts both periods. Attributing effort where it was actually spent needs either in-sprint status transitions or an accepted simplification. Either is fine. An unstated one is not.
Once effort is attributed to a project and a period, cost follows from the loaded rate for the people involved.
project_cost(project, period)
= SUM over engineers of
loaded_cost(engineer, period)
x effort_share(engineer, project, period)
Two cautions.
Use loaded cost, not salary. Employer taxes, benefits, and directly attributable overhead all belong in the figure. Which specific components belong is a policy question for your accountants, not a systems one. The system's job is to take whatever definition they set and apply it consistently.
Keep the rate as of the period. People get promoted and change teams. A model that applies today's rate to last year's effort will not reconcile to last year's payroll, and reconciling to payroll is the check that proves the model is not inventing money.
The output is not the allocation. The output is the allocation plus the path back to the records that produced it.
For a given capitalized amount, that path should run: amount, to the policy rule that classified it, to the effort share it was derived from, to the sprint and tickets behind the share, to the payroll line behind the cost. Five hops, each one a link rather than an explanation.
That is what turns a review question from a research project into a lookup. It also has a second benefit that shows up sooner: when the number looks wrong, you can find out why in minutes instead of rebuilding the calculation.
Do not ask engineers to categorise their own work for accounting purposes. They will do it inconsistently, resent it, and the output will be worse than what you can derive. Categorisation is a policy question and belongs in the rules layer.
Do not build the allocation inside the spreadsheet that holds the schedule. That merges the activity record with the treatment and puts you back where you started: a file that has to be rebuilt when anything changes.
Do not chase precision you cannot use. Allocating to the hour when the schedule is monthly and the rules are project level adds work and no accuracy. Match the granularity to what the rules actually read.
The first step is smaller than it sounds, and it is not a systems project. Take one month that has already closed. Derive the allocation from sprint data using whatever conventions you would pick. Compare it to what the tracker said for that month.
If the two are close, you have just found a defensible derivation for a number you were previously estimating. If they are far apart, you have found something worth understanding before the next close, which is more valuable.
Either way you now know whether the data supports the derivation, before anyone has built anything.
Not sure where your process sits?
Engineering activity to capitalized asset, with the evidence attached to every amount.