How TargetBoard Calculates AI ROI & Productivity Lift

TargetBoard reports two metrics that show the real value of your AI tools: Productivity Lift and AI ROI. This page explains what each means, how it is calculated, and which settings should be tailored for your organization.

Metric:	Answers:	Shown As:
Productivity Lift	Is the team shipping more work than before AI tools were used?	A percentage change, e.g. +50%.
AI ROI	Is that extra work worth more than what you're paying for the tools in use?	A multiplications factor, e.g. 17x.

An AI ROI of 17x means every $1 spent on AI tools returned $17 of net gain, after the cost of the tools is subtracted. Both metrics start from the same measurement, ensuring they tell a consistent story.

Measuring Output

Output is measured as pull requests merged to your main branch - work that has been written, reviewed and accepted into your product. Work that is never merged, or merged only to a side-branch, is not counted.

How the calculation works:

Set a pre-AI baseline - using a benchmark period before your organization adopted AI tools, TargetBoard measures how many Pull Requests were merged per developer per month to establish the baseline.
Compare current output to baseline - Productivity Lift = Pull Requests merged this month ÷ monthly baseline. A result of 1.5 means 50% more output and is shown as +50%.
Convert the extra output to value - extra output represents engineering time that would otherwise have been needed to achieve the same outcomes. The pricing calculation is based on figures provided by your organization in order to accurately reflect the return. Value = extra output x daily productive coding hours x monthly working days x hourly engineering cost.
Subtract your AI tool spend - Net gain = value of extra output - AI tool spend. Your AI ROI = net gain ÷ AI tool spend. Your spend includes every AI tool connected to your TargetBoard account.

For your whole organization, TargetBoard totals net gain and spend across all developers, so a few outliers do not skew the result.

Keeping the numbers fair:

The following safeguards are in place to prevent your metrics from overstating the impact of AI tools:

Time away is excluded from baselines - months when a developer was on leave or before they joined are excluded from their baseline instead of counting as zero output. This prevents productivity after any sort of absence from appearing as AI-driven gains.
Very small baselines use the company average - if a developer merged only a handful of pull requests during the benchmark period, their history is too thin to compare against. Their baseline is replaced with the company-wide average.
Value is priced over working days - extra output is valued over working days per month (generally 21), not calendar days.

Settings Configured to Your Account

Five settings shape these metrics and should be configured to your account in order to most accurately generate your metrics. These can be adjusted at any time by contacting your TargetBoard Customer Success Manager.

Setting	Default	What it Controls
Benchmark period	None.	Pre-AI period that baselines are measured from.
Average loaded cost per engineer	$170K per year	Annual fully loaded cost used to price engineering time.
Daily productive coding hours	5 hours	Average part of the working day used to produce shippable work.
Monthly working days	21 days	Number of days extra output is valued over.
Minimum baseline threshold	25% of company average	How small a personal baseline can be vefore the company average is used instead.

Best Practices:

Choosing a benchmark period has the biggest effect on your results.

It should end before AI tools were rolled out. Overlap makes the improvement look smaller than it is.
A three-month period is recommended. Shorter periods produce less reliable baselines.
Metrics are reported from the end of the benchmark period. They appear once both a start and end date are set for your account.

Other settings:

Average loaded cost should reflect your full cost per engineer, including benefits and overhead, not base salary alone.
Productive coding hours should be conservative by design. It should allow for meetings, code review planning and other activities.
The minimum baseline threshold can be raised if you prefer to compare more developers against the company average.

Limitations

These metrics are best used to track and compare trends over time. Keep the following in mind when reading them:

Only developers who merged work are included. Developers with no merged pull requests in a month are not counted, and neither is their tool spend. This can make ROI appear slightly higher than a full-team view would show.
Early months are indicative. Until all AI tool billing is connected, spend may be understated and ROI overstated as a result.
The current month reads low. A partial month is compared against a full-month baseline, so the figure fully settles once the month ends. Additionally, some integrations have a 3-day delay before data is received by TargetBoard. As a consequence, we recommend reviewing this data on or after the 4th of the following month.
Size and quality are not measured. A team that moves to smaller, more frequent pull requests will show higher output. Productivity Lift reflects throughput, not the value of each change.
ROI is an estimate, not an accounting figure. AI ROI models the value of time saved. I should not be used to book cost savings.