How we calculate the rework cost of a definition change
Story points, role day rates and ticket status. Why the figure is plain arithmetic, how gaps are handled, and why no AI model is involved.
When a business definition changes after work has already been built on it, someone pays for the rework. Usually nobody knows how much, which is why the change was not controlled in the first place.
SynkBase puts a figure on it. This post explains exactly how, because a cost number is only useful if the person reading it can check where it came from.
The short version
For each work item affected by a definition change:
effort days = story points × hours per point ÷ hours per day
base cost = effort days × role day rate
rework cost = base cost × status multiplier
The rework cost of the change is the sum across every affected work item.
Where each input comes from
| Input | Source | Who sets it |
|---|---|---|
| Story points | The work item in your tracker | Your team, as part of normal estimation |
| Ticket status | The work item in your tracker | Your workflow |
| Hours per point | Configuration | Your organisation, once |
| Role day rate | Configuration, per role | Your organisation, once |
| Status multiplier | Configuration, per status | Your organisation, once |
Nothing in the table is guessed by SynkBase. Points and status are read from the tracker. Everything else is a value your organisation chooses and can change, and every change to it is versioned.
Why the status multiplier exists
The same ticket costs different amounts to redo depending on how far it has got. A ticket not yet started needs its description updated. A ticket in progress needs work thrown away. A ticket already released may need a fix, a retest and a release of its own.
The multiplier encodes that. Your organisation sets the values per status. A worked example with illustrative numbers:
- 5 story points, at 6 hours per point and an 8-hour day, is 3.75 effort days.
- At a role day rate of €720, that is €2,700 of base cost.
- The ticket is in progress, with a multiplier of 1.5, so the rework cost is €4,050.
Those inputs are examples, not benchmarks. Your rates and multipliers will be different, and they should be.
What happens when data is missing
A work item with no story points is listed as unpriced, and the total says how many unpriced items it leaves out. Treating a missing estimate as zero would make the number look smaller and more certain than it is.
Likewise, if the impact traversal stops at a configured limit, the affected set may be incomplete. In that case every figure derived from it is shown as a lower bound, for example “≥ €38,000”, never as an exact total.
Why no AI model is involved
We could have asked a language model to estimate the cost of a change. We chose arithmetic because a finance director or an auditor will ask where the number came from, and they will not accept “a model estimated it”.
Deterministic arithmetic gives the same result every time the same inputs are used. A figure from last quarter can be recalculated exactly, and every total opens up to the individual tickets behind it.
AI does have a place in SynkBase, for example proposing which tickets might implement a term. Those suggestions go into a review queue. A person confirms them before they affect any figure.
Why bother putting a number on it at all
Without a figure, definition governance competes with feature work on intuition, and loses. With a figure that traces back to the tracker, the conversation changes from “is this worth controlling?” to “this change will cost this much, do we still want it this way?”
SynkBase’s rework cost is built for that conversation. If you want to try it on a real change from your own history, that is part of our design partner programme.