AI ROI Calculator: Inputs, Formulas, and a Worked Example
TL;DR: A defensible AI return on investment (ROI) calculation uses linear regression to correlate token spend with delivery outcomes such as roadmap value delivery and on-time delivery rate. The regression slope is the ROI readout, for example story points completed per dollar, while R-squared shows how much of the variation spend explains. A spreadsheet can run it with data from your version control, project management, and AI coding tools. Keeping that data normalized every reporting cycle is where manual builds stall. minware's AI impact reports run the same regression on connected data, with the slope and R-squared shown next to editable formulas.
Engineering teams collect token usage data from tools like GitHub Copilot or Claude Code and track output on delivery dashboards, but no single number connects the two. Without that number, AI coding tool spend is hard to evaluate. Finance teams now apply the discipline built for cloud costs to AI, with 98% of FinOps practitioners managing AI spend.
The missing number matters because finance leaders check the math themselves. In a Wynter survey of 300 business-to-business (B2B) leaders, 58% of financial leaders said they don't trust vendor ROI calculations, and 56% build their own ROI frameworks. A calculator built on adoption rates or lines of code generated outputs a percentage that collapses under scrutiny in an executive review. This article walks through the inputs, formulas, and a worked example for a 50-engineer team over one quarter, giving you a method you can rerun on your own data.
Gathering the inputs for your AI ROI model
A defensible AI ROI calculation draws on three systems. Token spend comes from your AI coding tools. Delivery outcomes come from your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps, and your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues. Token spend is the independent variable, while the delivery outcomes are the dependent variables.
Most AI coding tools now expose usage data, including token consumption, through vendor APIs or OpenTelemetry integrations. GitHub Copilot generates usage metrics reports daily, as single-day reports or a rolling 28-day report, and single-day reports reach back up to one year. Cursor's Admin API returns per-request token consumption and cost. Claude Code reports cost and token usage through OpenTelemetry as well as its analytics APIs. These sources feed the metrics below.
Defining token spend
Token spend is the dollar cost of AI tool usage, a separate data point from the count of tokens processed. AI tool APIs and OpenTelemetry integrations generally report what token cost would be on a consumption-based plan with no discount. For users on flat-rate plans such as Claude Pro, reported spend may differ from the amount actually paid. Where significant discounts exist, multiply reported token costs by the total bill divided by total reported spend to approximate the average discount.
This adjusted figure is the continuous variable you regress delivery outcomes against. Collect it per team per time period, such as per week or per month, so each team contributes several data points.
Measuring roadmap value delivery
Roadmap value delivery is the expected value of completed work, and it is the primary value metric for this calculation. Teams can configure it to an explicit value field set during roadmap planning. Where no value field is configured, it defaults to story points completed on tickets that are not bugs and have a parent epic, with 1 point per ticket that has no estimate.
Filtering out bugs and unparented tickets keeps maintenance work out of the measure. Where teams estimate in different units, convert them to a common scale or run separate regressions per estimation scheme.
Measuring on-time delivery rate
On-time delivery rate measures whether teams deliver roadmap items on the schedule they set. For each roadmap item, divide the estimated duration (from when the item is marked in progress until the due date set at that time) by the actual duration (from in progress until done), capping the result at 100%. Average the result across the items a team completed in the period.
By default an epic is the roadmap item, though higher-level tickets work too. This value metric sits alongside roadmap value delivery to show whether AI spend correlates with predictability as well as volume. It needs only ticket status history from your project management system.
Tracking quality and efficiency guardrails
Bug rate and PR lead time are guardrail metrics that explain why a delivery trend moves. Bug rate divides bugs created by pull requests merged, capturing quality problems that change failure rate misses. DORA tracks instability through change failure rate and deployment rework rate. Bug rate gives a broader view of defects alongside them.
PR lead time runs from a pull request's first commit to deployment, which defaults to merge into a main branch. Ticket cycle time, from in progress to done, is the second efficiency guardrail. As AI spend rises, cycle time should hold steady or fall, which shows the spend isn't creating a bottleneck further down the pipeline. If roadmap value delivery rises while bug rate climbs sharply, the ROI reading has to account for the rework cost behind it.
| Metric | Category | Source system | Calculation note |
|---|---|---|---|
| Token spend | Input | AI tool APIs, OpenTelemetry | Dollar cost at list price, adjusted for plan discounts |
| Roadmap value delivery | Value | Project management | Story points completed on non-bug tickets with a parent epic, by default |
| On-time delivery rate | Value | Project management | Estimated duration divided by actual duration, capped at 100% per item |
| Bug rate | Quality | Version control, project management | Bugs created divided by pull requests merged |
| PR lead time | Efficiency | Version control | First commit to deployment, merge to main by default |
| Ticket cycle time | Efficiency | Project management | In progress to done |
Choosing metrics that hold up in an executive review
An AI ROI number fails in review when it correlates spend with the wrong outcome. The claim most worth rebutting treats pull requests merged as AI ROI. A rise in merged pull requests shows code output went up without showing that the code delivered value. Lines of code and commits share the same limit, since all three are throughput metrics. Pair token spend with value delivery metrics first, then use efficiency and quality metrics to explain the trend.
Headline speedup figures often come from single, well-defined tasks. In a controlled experiment, developers given GitHub Copilot built an HTTP server in JavaScript 55.8% faster than developers without it. A task like that leaves out the integration work, debugging across legacy systems, and requirements clarification that fill much of an engineering calendar. A continuous regression against your own delivery data covers the full mix of work your team actually does.
Applying the regression formulas
The core calculation is simple linear regression, written as Y = mX + b. Y is the delivery outcome, X is token spend, m is the slope, and b is the intercept. The slope is the estimated change in the outcome for each additional dollar of token spend, such as story points per dollar. A standard way to compute it is m = Σ[(Xi - X̄)(Yi - Ȳ)] / Σ[(Xi - X̄)²], which divides the covariance of spend and outcome by the variance of spend. R-squared, on a 0-to-1 scale, is the share of the outcome's variation that spend explains.
Running one regression per outcome
Each regression fits a single metric pair, so three outcomes need three regressions. minware's Lean AI Framework regresses three business outcomes separately against token spend: roadmap value delivery, on-time delivery rate, and overhead cost. Quality and efficiency metrics such as bug rate stay in the guardrail role.
Read the incremental ROI off each slope. The worked example below, for instance, finds a slope of about 0.0059 story points per dollar, so each additional $1,000 of monthly token spend is associated with about 5.9 more story points completed. Normalize each data point to per person-day, dividing spend and the outcome by active contributor work days, so team size doesn't distort the slope.
Regressing on-time delivery rate and overhead cost
Regress on-time delivery rate against token spend the same way, using each team's rate for each period. The slope reads in percentage points per dollar. A positive slope means higher spend is associated with teams finishing roadmap items closer to the schedule they set. A negative slope means higher spend coincides with more slippage, which is a cue to check ticket cycle time and bug rate for the cause.
Overhead cost, the third outcome, covers personnel cost and token spend that can't be traced to roadmap work. Regress it the same way to see whether higher spend is growing the cost that sits outside the roadmap.
Checking each team's trend over time
The supporting check is each business outcome's trend over time for the same team as AI maturity increases. Comparing a team with itself controls for differences between teams that can confound a regression across teams. If one team's roadmap value delivery rises alongside its token spend over four quarters, that trend supports what the cross-team regression shows.
If the trend runs flat while spend climbs, the regression slope deserves a closer look before it reaches a board deck. Track several periods per team, since one quarter is a short window to establish direction.
Accounting for selection bias
Selection bias occurs when the people or work using AI differ systematically from the rest. Early adopters may already be stronger performers. They may also work mostly in newer code, where a 2026 longitudinal study found AI productivity gains concentrated. Task choice adds a third bias, since engineers may reach for AI on the tasks where it's most likely to help.
Non-AI groups are disappearing as adoption spreads, with over 70% of Stack Overflow's 2026 survey respondents using AI daily. The ones that remain are prone to selection bias, which makes AI-assisted vs. non-AI cohort comparison unreliable. Regressing against token spend as a continuous variable includes non-AI work as the zero-spend endpoint, so it needs no binary split. Selection bias still affects the regression, which is why these confounders need naming whenever you draw a conclusion from it.
Working through a 50-engineer example
This worked example uses illustrative data for a hypothetical 50-engineer B2B software as a service (SaaS) company over one quarter. The numbers are constructed to demonstrate the calculation and don't represent any actual company or customer outcome.
Setting up the example
The example company runs five teams of 10 engineers each, using GitHub for version control and Jira for project management. Their AI tools are GitHub Copilot plus Claude Code, and leadership wants a Q1 ROI reading for that spend ahead of a board review.
Each team contributes one data point per month, giving 15 team-month data points for the regression. Because every team has the same headcount and roughly the same working days, the example skips per person-day normalization to keep the numbers readable. With real data, normalize before you regress. The example covers the two value outcomes. Overhead cost follows the same steps once personnel cost is attached to each team-month.
Recording the monthly inputs
| Team | Month | Token spend | Story points completed | On-time delivery rate | Bug rate | PR lead time (hrs) |
|---|---|---|---|---|---|---|
| Platform | Jan | $3,800 | 34 | 76% | 0.25 | 19 |
| Platform | Feb | $4,100 | 45 | 79% | 0.24 | 18 |
| Platform | Mar | $4,500 | 40 | 81% | 0.24 | 18 |
| Frontend | Jan | $2,500 | 42 | 72% | 0.30 | 23 |
| Frontend | Feb | $2,700 | 36 | 70% | 0.32 | 25 |
| Frontend | Mar | $3,000 | 44 | 73% | 0.31 | 24 |
| Backend | Jan | $4,600 | 43 | 80% | 0.21 | 15 |
| Backend | Feb | $5,200 | 49 | 82% | 0.20 | 14 |
| Backend | Mar | $5,800 | 55 | 84% | 0.19 | 14 |
| Mobile | Jan | $1,800 | 24 | 69% | 0.34 | 27 |
| Mobile | Feb | $2,000 | 33 | 67% | 0.36 | 29 |
| Mobile | Mar | $2,300 | 26 | 70% | 0.35 | 28 |
| DevOps | Jan | $1,400 | 31 | 74% | 0.28 | 20 |
| DevOps | Feb | $1,600 | 20 | 75% | 0.29 | 21 |
| DevOps | Mar | $1,800 | 28 | 76% | 0.28 | 20 |
All figures in this table are illustrative and constructed for this example.
Token spend is the API-reported cost at list price. Story points completed counts closed non-bug tickets with a parent epic, the default for roadmap value delivery. On-time delivery rate is the average of each epic's estimated-to-actual duration ratio, capped at 100%. Bug rate is bugs created divided by pull requests merged. PR lead time is the median hours from first commit to merge.
Reading the regression output
Regressing story points completed against token spend across the 15 team-months gives a slope of 0.0059 points per dollar, or about 5.9 points per $1,000 of monthly spend. R-squared is 0.72, so token spend explains 72% of the variation in story points completed across these data points.
The intercept is 18 points. The lowest spend in the data is $1,400 per month, so the intercept falls outside the observed range and shouldn't be read as delivery at zero AI spend. On-time delivery rate gives a slope of 0.003 percentage points per dollar, about 3 percentage points per $1,000, with an R-squared of 0.68.
Checking quality and efficiency guardrails
The guardrails point in the right direction in this example. Bug rate falls as spend rises, with a slope of -0.000032 per dollar (R-squared 0.69). PR lead time also falls, at -0.0026 hours per dollar, or about 2.6 hours per $1,000 (R-squared 0.57). Neither signal suggests the AI spend is lowering quality or slowing pull requests on their way to merge.
For the same-team check, Backend's story points completed rose from 43 in January to 49 in February and 55 in March as its spend grew from $4,600 to $5,800. A single quarter is a short window, so treat this trend as a starting point for the supporting check.
Converting the slope into dollar value
Calculate ROI by comparing the marginal delivery gain against the marginal cost. Suppose the organization assigns each story point an expected value of $800, for example through an explicit value field set during roadmap planning. At a slope of 0.0059 points per dollar, each additional $1,000 of monthly spend is associated with about 5.9 more story points.
At $800 per point, that is about $4,700 of value per $1,000 spent, a strongly positive return on the marginal dollar. Name the confounders alongside that number. Engineers using more AI may be working in newer code, and early adopters may be stronger performers regardless of tooling.
Putting the formula to work
You can run this calculation in a spreadsheet using the template below, or automate it through a platform with normalized data. The spreadsheet works for a one-time analysis. It gets harder to sustain when different stakeholders ask "how exactly is this calculated" every month.
Building the spreadsheet template
Build a sheet with these columns in this order: Team (A), Period (B), Token Spend (C), Story Points Completed (D), On-Time Delivery Rate (E), Bug Rate (F), and PR Lead Time (G). Add one row per team per period. In Excel or Google Sheets, compute the slope with =SLOPE(D2:D16,C2:C16) and R-squared with =RSQ(D2:D16,C2:C16) for 15 rows, adjusting the ranges to your data.
Repeat with column E for on-time delivery rate, then with columns F and G for the guardrails. Pull AI tool usage data from vendor APIs, OpenTelemetry integrations, or the admin console, matching its time periods and team groupings to your ticketing data.
Deciding when to automate
Automate when the spreadsheet becomes a recurring reporting burden or when stakeholders challenge the methodology. A manual pipeline needs an owner as vendor APIs and OpenTelemetry formats change. It also has to solve three data problems before any slope can be trusted. The first is relationship recovery, linking agent sessions, commits, pull requests, and tickets that carry no structured connection. The second is identity resolution, matching each developer across systems. The third is data normalization, putting vendor formats into one model.
minware's AI impact reports run these regressions on connected data, showing the slope and R-squared next to editable formulas you can inspect in an executive review. The table below compares the two paths.
| Dimension | Build (custom pipeline) | Buy (platform) |
|---|---|---|
| Initial setup | Multiple weeks of engineering time to build the data pipeline | Many analyses work once data is connected. Org-specific metrics need configuration, usually handled by customer success |
| Entity resolution and normalization | Manual identity matching and format mapping. No way to link sessions, commits, or tickets that lack explicit IDs | Relationship recovery, identity resolution, and data normalization via minware's patented hypercube data model |
| Formula transparency | Logic spread across cell references | Visible, editable formulas in the UI |
| API maintenance | Recurring updates as vendor APIs change | Compatibility handled by the platform vendor |
| Stakeholder questions | Answered by whoever built the sheet | Data lineage available for every metric |
Avoiding common calculation errors
These five errors make an AI ROI number hard to defend:
-
Pull requests merged as ROI evidence: Pull requests merged is a throughput metric, so it can't carry an ROI claim alone.
-
Bucketed spend: Grouping token spend into low, moderate, and high tiers discards information from a continuous variable. It also reintroduces the cohort-comparison problems regression avoids.
-
Totals divided by totals: Total outcomes divided by total spend attributes all delivery to AI, including work people would have shipped anyway. It's also undefined for zero-spend work.
-
Before/after snapshots: A single pre/post comparison is fragile unless it accounts for selection bias and changes in team composition.
-
Adoption metrics: Seats activated or prompts accepted show the tool is in use. Neither shows delivery impact on its own.
Understanding the limits of AI ROI modeling
AI ROI modeling shows whether higher token spend correlates with improved delivery outcomes. Proving causation would also require controlling for confounders like task complexity, developer seniority, and codebase age. The slope and R-squared describe the association in your data. The confounders above set how far you can lean on it.
Reading token spend as a continuous variable
Token spend works as the input because it is continuous, with zero-spend work as its natural endpoint. As AI adoption saturates, spend level stays the variable that answers the CFO's question: is higher spend buying more delivery, or just a bigger bill? Some teams use AI heavily while others use it lightly, so the variation the regression needs persists even at full adoption. Adoption counts can't do this job, because once every engineer has a seat they stop varying.
Targeting teams for AI investment
Regression results also show where more AI investment is likely to pay off. If Backend shows a steeper slope than Mobile when each is regressed on its own periods, check whether Mobile's codebase or task mix limits what AI can do there.
Hygiene metrics such as PRs Traceable to Ticket, on the Best Practices report, show where weak linking undercounts AI-assisted work in roadmap value delivery. Code-side metrics such as bug rate and PR lead time come from version control, so they don't depend on ticket linking.
Setting the bounds of the calculation
A regression on a handful of data points is unstable, so use as many team-weeks or team-months as your data allows. The model assumes a linear relationship between spend and outcomes, which may not hold at very high spend levels. Reported token spend can differ from the amount actually paid on flat-rate plans, so apply the discount adjustment before regressing. Statistical significance isn't part of the readout, so export the data to a statistics tool if a stakeholder asks for it. Imperfect linking between systems doesn't block the method, and hygiene metrics show where to clean it up over time.
Running your own AI ROI calculation
Regressing roadmap value delivery against token spend gives a slope in value per dollar, which is the ROI answer a board needs. On-time delivery rate and overhead cost follow the same steps. Bug rate and cycle time serve as guardrails throughout. The worked example shows how to read the slope and R-squared from your own data. Each team's trend over time is the supporting check, controlling for differences between teams. You can run the whole calculation in a spreadsheet, or connect your data to a platform that keeps the formulas visible without a monthly rebuild.
Start a 14-day free trial at minware.com, no credit card required. Connect your version control, project management, and AI coding tools to see the regression on your own data.
FAQs
Is there a calculator for AI coding tool ROI?
Yes. minware's AI impact reports regress delivery outcomes against token spend automatically, with the slope as the ROI answer. You can also run the calculation in a spreadsheet using token spend, roadmap value delivery, and on-time delivery rate data from your existing tools.
What if my data is too messy for an AI ROI calculator?
minware works with data as it exists today, and its hygiene metrics such as PRs Traceable to Ticket show exactly where process gaps exist. minware's patented hypercube data model recovers relationships between entities that lack explicit links, so analysis can start before source data is fully cleaned up.
How often should I recalculate AI ROI?
Recalculating quarterly lines up with board reporting cycles. Monthly suits teams actively adjusting AI tool spend or rollout practices. Each team's trend over time needs several periods before its direction is clear, so a regular cadence also builds the supporting check. minware refreshes its AI impact reports with each nightly data ingest, so the regression stays current between reviews.
Can I use adoption metrics instead of token spend?
Not as ROI evidence. Adoption metrics such as seats activated or prompt counts show whether a tool is in use, without showing delivery impact. Token spend level scales with how intensively teams use AI, so it can answer whether higher spend buys more delivery.
Key terms glossary
Token spend: The dollar cost of AI tool usage, as reported by AI tool APIs or OpenTelemetry. On flat-rate, tiered, or discounted plans, reported spend may differ from the amount actually invoiced.
Story points completed: The total of the story points field for completed tickets.
Roadmap value delivery: The expected value of completed work items. Configurable to any project management field where a team sets explicit value estimates during roadmap planning. If no explicit value field is configured, defaults to story points completed on tickets that are not bugs and have a parent epic, with 1 point assigned per ticket if no estimate is set.
On-time delivery rate: The estimated roadmap item duration (time from when a roadmap item is marked in progress until the original due date set at that time) divided by the actual roadmap item duration (time from in progress until it is marked done), capped at 100% per roadmap item.
Overhead cost: Personnel cost and AI token spend that goes toward work not counted in roadmap value delivery, meaning cost not traceable to any ticket, or traceable to a ticket excluded from roadmap value delivery, such as a bug ticket or a ticket with no parent epic.
Linear regression: A statistical model charting the best-fit line between an outcome metric and an input variable. Each regression fits one metric pair, so correlating spend against multiple outcomes requires a separate regression for each.
Regression slope: The change in an outcome metric per unit change in the input variable, such as story points completed per dollar of token spend.
R-squared (R²): In a regression chart, the share of the outcome metric's variation explained by the input variable, on a 0-to-1 scale.
Selection bias: Systematic differences between the people or work using AI and the rest, which can distort cohort comparisons as well as regressions.
Bug rate: A quality metric measuring the number of bugs created divided by the number of pull requests merged into a main branch, by default.
PR lead time: The time from a pull request's first commit to when it was deployed. Deployment defaults to when the code merges into a main branch.
Ticket cycle time: The time from when a ticket was first marked in progress to when it was completed.
Entity resolution: Matching a developer's identity across systems (identity resolution) plus recovering links between commits, tickets, pull requests, and AI agent sessions that carry no structured connection (relationship recovery).
Data normalization: Standardizing messy vendor data formats into one consistent model so concepts can be connected across tools.
Hypercube data model: minware's patented data model that links every entity from every data source, so any metric can be broken down by any dimension.