Say-Do Ratio in Jira: Formula, Target Range, and the Rework Connection
Updated June 2026
The say-do ratio in one card
The say-do ratio is the ratio of what a team said it would deliver to what it actually delivered. At sprint level it is the committed story points completed divided by the story points committed at sprint start.
Say-Do Ratio = (committed points completed / points committed at sprint start) x 100Target band: 80 to 100% (SAFe Program Predictability). Below 80% signals systemic planning or execution problems; consistently above 100% suggests the team is under-committing. Jira has no native say-do field, so you calculate it from the built-in Sprint Report.
The say-do ratio (also written say/do ratio) is a predictability metric, not a productivity one. It does not reward a team for doing more work; it rewards a team for delivering the work it committed to. That distinction matters because the value of the metric is trust: a team whose say-do ratio sits stably inside the target band is a team whose sprint commitments stakeholders, dependent teams, and customers can plan around. A team that overruns its commitments every sprint forces everyone downstream to discount its promises.
This page covers the two levels the metric is used at (sprint and Program Increment), how to calculate it in Jira where there is no built-in field for it, the target range, and the part most teams miss: why unplanned rework is the single biggest reason a say-do ratio falls.
Two levels: sprint and Program Increment
The same idea is measured at two scales, with two different numerators and denominators. Both land on the same 80 to 100% target band.
| Level | Numerator / denominator | Where the numbers live |
|---|---|---|
| Sprint commitment reliability | Committed story points completed / story points committed at sprint start | Jira Sprint Report |
| SAFe Program Predictability | Actual business value achieved / planned business value (per PI objective) | PI objectives scored at the Inspect & Adapt event |
In SAFe terminology the formal name is the Program Predictability Measure: each PI objective is assigned a planned business value at planning and an actual business value at the Inspect & Adapt event, and the ratio of actual to planned is the predictability score. The colloquial name teams use for the same idea is the say-do ratio. SAFe places reliable trains in the 80 to 100% range. The sprint-level calculation below is the team-level equivalent of the same measure.
How to calculate the say-do ratio in Jira
Jira does not have a say-do ratio field or report. You build it from the data already in the Sprint Report, which records the scope at sprint start and what happened to each issue. The steps:
Step 1: Open the Sprint Report
Backlog > Reports > Sprint Report, and select the sprint you want to score. The report separates 'Completed Issues' from 'Issues Not Completed', and flags issues added to the sprint after it started (these carry a marker so you can exclude them).
Step 2: Establish the committed scope (the denominator)
The denominator is the story-point total at sprint start, before any mid-sprint additions. Sum the story points of every issue that was in the sprint when it began. Do not include issues added later: adding scope and then completing it does not make a team more predictable about its original commitment.
Step 3: Establish committed work delivered (the numerator)
The numerator is the story points of the originally committed issues that reached Done by sprint end. Completing an issue that was added mid-sprint does not count toward the numerator either; only originally committed, completed work does.
Step 4: Divide and track the trend
Say-do ratio = numerator / denominator x 100. A single sprint is noise. Plot the ratio across the last 6 to 8 sprints. A stable line inside 80 to 100% is the goal; a downward trend is the signal to investigate, and the first place to look is unplanned rework.
JQL: isolate the unplanned work that ate the sprint
The Sprint Report gives you the say-do numbers. To explain a low ratio, isolate the mid-sprint rework that displaced committed scope. This query surfaces the rework issues completed in the current sprint, the work most likely to have pushed committed stories out:
project = "YOUR_PROJECT" AND sprint in openSprints() AND labels in (rework, hotfix, regression, bug-fix, incident-response) AND status = Done ORDER BY created DESC
Sum the story points here. If this number is a large share of your sprint capacity, your say-do ratio is being driven down by rework, not by over-commitment or estimation error. The full set of rework-tracking JQL recipes is on the how to measure rework page.
How to chart the say-do ratio in Jira: the Velocity Chart and dashboards
Jira has no built-in say-do ratio report or dashboard gadget: the name is not a Jira concept. The closest native view is the Velocity Chart, which already plots the two numbers the say-do ratio is built from. On a company-managed Scrum board, open Reports > Velocity Chart.
Reading the say-do ratio off the Velocity Chart
Each sprint shows two bars. The grey Commitment bar is the total estimate of every work item in the sprint when it began; per Atlassian's documentation, stories added after the sprint starts and later estimate changes are excluded from it. That is exactly the say-do denominator. The green Completed bar is the estimate completed by sprint end, the numerator.
So the ratio of the green bar to the grey bar for any sprint is that sprint's say-do ratio, read straight off the chart. Because the grey bar freezes at sprint start and ignores mid-sprint additions, the Velocity Chart measures commitment reliability rather than throughput, which is what you want.
The catch is where it lives. The Velocity Chart is a board-level report, not a dashboard gadget: you cannot pin it to a shared Jira dashboard alongside other metrics, and it shows only the most recent sprints, so it will not give you a long say-do trend line on its own.
To put a say-do ratio chart or report on a dashboard, there are two routes:
- Spreadsheet export. Record the Commitment and Completed points per sprint (from the Velocity Chart or the Sprint Report) and plot
completed / committed x 100as a percentage trend line against the 80 to 100% band. This is the most portable option and it keeps the definition under your control. - Marketplace gadget. Several Atlassian Marketplace apps add a commitment-reliability or say-do gadget you can drop straight onto a Jira dashboard. Check exactly how each app defines its denominator (scope at sprint start versus final scope) before you trust the number, because the two definitions answer different questions.
What a say-do ratio chart looks like (worked example)
Below is an illustrative say-do ratio chart for one team across six sprints: one bar per sprint, each bar the ratio of completed to committed points, plotted against the shaded 80 to 100% target band. This is the shape you are building toward on a dashboard, whether from a spreadsheet export or a Marketplace gadget. The numbers are an example, not benchmark data.
Two sprints (S2 at 71%, S5 at 73%) fall below the band, shown in red. On a real dashboard the next question is always the same: pull the rework JQL above for those two sprints. If unplanned rework accounts for the shortfall, the say-do dip is a quality signal, not an estimation one. A single bar is noise; the value is in the trend line across six to eight sprints and whether it sits inside the band.
What is a good say-do ratio?
< 80%
Systemic problem
Planning or execution is breaking down. Stakeholders cannot rely on commitments. Investigate root cause before anything else.
80-100%
Reliable (target)
Roughly 4 of 5 committed items land. Stakeholders can plan. SAFe's target band for a predictable train.
> 100%
Sandbagging
Consistently beating commitment by a wide margin means the team is under-committing. Predictable, but leaving capacity on the table.
The most common misreading is treating 100% as the goal and anything below it as failure. It is not. A team that hits exactly 100% every sprint is almost certainly padding estimates or under-committing to guarantee the number. SAFe is explicit that perfection is not the target: teams are solving problems that have never been solved before, and a healthy train lives inside the band rather than pinned to its ceiling. Stability matters more than the absolute figure: a team steady at 85% is more plannable than one swinging between 70% and 110%.
Why rework is the say-do ratio's biggest enemy
When a say-do ratio falls, the instinct is to blame estimation: the team committed to too much. Sometimes true. More often the team committed to a reasonable amount and then spent a chunk of the sprint on work it never planned, because production broke, a regression surfaced, or a hotfix could not wait. That unplanned work is rework, and it is invisible in the say-do number itself. The committed scope simply slips, and without tagging you cannot tell whether the cause was bad planning or a quality problem upstream.
This is why the say-do ratio and the sprint rework percentage should be read together. A low say-do ratio next to a high rework ratio is the unmistakable signature of a predictability problem that is really a quality problem: the team is not failing to plan, it is being forced to spend planned capacity fixing the past. Chasing it with better estimation will not help. Reducing the inflow of defects will. The cost-of-change curve explains why catching defects earlier is the lever (see the Boehm cost-of-change curve).
The practical move: every time the say-do ratio dips below the band, pull the rework JQL above for that sprint. If unplanned rework accounts for the gap, the fix sits in prevention and earlier defect detection, not in the planning meeting. The reduce rework playbook covers the levers in order of payback.
Anti-patterns: how the say-do ratio gets gamed
Under-committing to guarantee the number
The fastest way to a 'good' say-do ratio is to commit to less than the team can do. The ratio looks healthy and the team delivers no more than before. This is why a ratio pinned above 100% is a warning, not a win. Read say-do alongside throughput so sandbagging shows up.
Counting mid-sprint additions in the numerator
If work added after the sprint started counts toward 'done', a team can rescue a failing sprint by pulling in easy unplanned tickets. The denominator must be frozen at sprint start, and only originally committed work can count toward the numerator. Otherwise the metric measures throughput, not reliability.
Tracking the ratio without tagging rework
A say-do ratio with no rework taxonomy tells you that you missed commitment but not why. Tag rework consistently (rework, hotfix, regression, incident-response) so a low ratio can be decomposed into 'we over-committed' versus 'rework ate the sprint'. The two have opposite fixes.
Tying the ratio to performance reviews
Once say-do becomes a number management uses to judge people, teams optimise the number rather than predictability: scope gets sandbagged, rework gets relabelled, commitments shrink. Use it for forecasting and retrospective diagnosis, not appraisal.
Frequently asked questions
What is the say-do ratio?▼
The ratio of what a team said it would deliver to what it actually delivered. At sprint level: completed committed story points divided by points committed at sprint start, as a percentage. It is a predictability and trust metric, not a productivity one.
How do you calculate the say-do ratio in Jira?▼
Jira has no native say-do field. Use the Sprint Report (Backlog > Reports > Sprint Report): sum the committed story points at sprint start (denominator), sum the committed points actually completed (numerator), and divide. Exclude scope added mid-sprint from both.
Does Jira have a say-do ratio report?▼
No. Jira has no built-in say-do ratio report or dashboard gadget. The closest native view is the Velocity Chart (Scrum board > Reports > Velocity Chart): the grey Commitment bar is points at sprint start (denominator), the green Completed bar is points done by sprint end (numerator), so green over grey per sprint is the say-do ratio. It is a board report, not a dashboard gadget, and shows only recent sprints, so a say-do trend on a dashboard needs a spreadsheet export or a Marketplace app.
How do you make a say-do ratio chart in Jira?▼
Jira has no built-in say-do ratio chart or gadget. The simplest chart is one bar per sprint whose height is completed committed points / committed points at sprint start, plotted against a shaded 80 to 100% band so sprints below the band stand out (see the worked example above). Build it two ways: export the Commitment and Completed points per sprint into a spreadsheet and chart completed / committed as a percentage trend line; or add a commitment-reliability / say-do Marketplace gadget to a dashboard, checking first how it defines the denominator.
Is there a say-do ratio report or gadget for a Jira dashboard?▼
Not natively. The Velocity Chart shows the two numbers the ratio is built from but is a board report you cannot pin to a shared dashboard. To get a say-do ratio report or graph onto a Jira dashboard you either maintain a spreadsheet export of committed versus completed points per sprint, or install an Atlassian Marketplace commitment-reliability gadget. Verify the gadget freezes the denominator at sprint start; otherwise it measures throughput, not commitment reliability.
What is a good say-do ratio?▼
The SAFe Program Predictability target band is 80 to 100%. Below 80% signals systemic planning or execution problems; consistently above 100% suggests under-committing. Stability inside the band matters more than hitting a perfect 100%.
How does rework affect the say-do ratio?▼
Unplanned rework is the biggest driver of a falling say-do ratio. Bugs, hotfixes, and regressions arriving mid-sprint consume capacity already committed to planned work, so committed scope slips. A low say-do ratio next to a high sprint rework ratio is a quality problem wearing a predictability problem's clothes.
Is the say-do ratio the same as velocity?▼
No. Velocity is throughput (points completed per sprint). The say-do ratio is predictability (how reliably the team delivers what it committed to). A team can have high velocity and a poor say-do ratio if it routinely completes unplanned work while dropping committed work.
Sources
- Scaled Agile, Inc. Program Predictability Measure and Metrics. SAFe (Scaled Agile Framework) guidance. (80 to 100% predictability target band)
- Atlassian. Jira Sprint Report and Velocity Chart documentation. 2026. (Sprint-start scope, completed vs not-completed, mid-sprint additions)
- Forsgren, N., Humble, J., Kim, G. Accelerate. IT Revolution, 2018. (Predictability vs throughput as distinct outcomes)