Use cases · Jira dashboards

Say-do ratio on a Jira dashboard: planned vs. actual per sprint

The say-do ratio is the simplest delivery metric there is: what the team committed to at the start of the sprint, against what it actually delivered by the end. Jira computes both halves — the Velocity chart is exactly this, per sprint — but keeps them on the board's reports page, as bars, with no ratio, no target and no way to put them next to the rest of a dashboard. Here is how to show the ratio on a Jira dashboard, and the one definition question to settle first.

What "committed" means — settle this first

Every say-do number depends on one choice: does work added after the sprint started count as commitment?

• Strict reading. Committed = the sprint's contents at the moment it was started. Issues added later are tracked separately as scope change; issues removed drop out of the base. This is what the Velocity chart's Commitment bar means, and what most teams mean by "say".
• Live reading. Committed = everything in the sprint right now. Simpler, always current, and it quietly rewards a team that adds small tickets it has already finished.

The Sprint Health Monitor gadget uses the strict reading (it reads the issue change history). A Plugio Suite sprint dashboard uses the live reading (it reads the sprint as it is now). Both are explained below; pick the one whose definition your retrospective actually uses.

What Jira shows natively

• Velocity chart (board → Reports) — two bars per sprint, Commitment and Completed, in the board's estimation statistic, for the last sprints. This is a say-do chart. It only lives on that board's reports page, shows no percentage, and cannot be placed on a dashboard or compared across boards.
• Sprint Report — for one sprint, the lists of completed, not completed, removed and added issues, with totals. The raw material for the ratio, as a report page.
• Sprint Health gadget — the active sprint's issues by status category as a bar, with time elapsed and a scope-change figure. One board, the active sprint only, fixed layout.
• Sprint Burndown gadget — the board's burndown embedded in the dashboard. A chart, not a number, and again one board.

Where these stop: no single percentage on a dashboard, no threshold colouring, no side-by-side of several teams, and no history of the ratio outside the Velocity chart's bars.

Which Plugio gadget?

Setup A — the strict ratio with Sprint Health Monitor

1. Add the gadget (Add gadget → "Sprint Health Monitor & Progress Bar") and open Configure.
2. Pick the board. The gadget always opens on the board's active sprint, so it rolls over by itself when a new sprint starts; a dropdown on the gadget lets any viewer flip to a closed sprint to read its result.
3. Choose the metric: issue count, story points or a numeric field. Story points should match the board's estimation statistic so the ratio agrees with the Velocity chart.
4. Set the goal — the dashed line at your target completion, 80 % by default. On a closed sprint it is the pass/fail bar.
5. Read it. The fill is done ÷ originally planned. Issues created or moved into the sprint after it started are excluded from the planned base and drawn as hatched segments — in the state colour when done, grey and packed at the far end when still open — so the main percentage keeps answering "how much of what we committed is finished". The stats block prints the ratio, the counts and +N % scope added mid-sprint.

Colour follows pace, not the ratio alone: green at or near the elapsed-time line, yellow more than ten points behind it, red when the sprint is more than half over and well behind — or, for a closed sprint, when it missed the goal.

Several teams on one dashboard

Switch the gadget to the Comparison layout and add up to four boards, all on Current sprint. Each battery shows its own sprint, ratio and state, so a delivery lead sees four teams' say-do at a glance.

Setup B — the ratio on a Suite sprint dashboard

Use this when the say-do number is one of several things the sprint review looks at. A Suite dashboard in sprint mode binds every widget to one sprint — the active one by default — and viewers flip to past sprints with the sprint chip.

1. Create the dashboard in Plugio Suite, choose the Sprint scope and pick the board. Leave the selection on Active sprint.
2. Add a Number widget with three value rows:
   Committed Sum of Story Points Delivered Sum of Story Points where statusCategory = Done Say-do {Delivered} / {Committed} * 100 ← the displayed row
   Give the formula row a "%" suffix, turn on Compare to previous period — on a sprint dashboard the baseline is the previous sprint — and add colour bands, e.g. below 70 red, 70–90 yellow, 90 and above green.
3. Prefer a dial? A Gauge with value Sum of Story Points where statusCategory = Done and a Dynamic target with an empty condition shows the same ratio as "% of target", with the bands on the arc.
4. Add the burnup. A Line widget with X axis Resolved, bucketed by day, Cumulative on and Show total scope line on: the curve is completed points, the dashed line is the sprint's total — committed vs. completed, over the sprint's dates.
5. Say-do per person. A Progress Bar widget, value Sum of Story Points where statusCategory = Done, grouped by Assignee, target Ratio in group: one bar per person, each filled to their own delivered ÷ assigned.
6. Save and share, or place the dashboard on a native Jira dashboard through the Plugio Suite Dashboard gadget.

The honest caveat: Suite reads the sprint as it is now. An issue added mid-sprint is part of Committed; an issue removed is gone from both sides. That is the live reading. If your retrospective insists on commitment at sprint start, put the Sprint Health Monitor gadget on the same dashboard for the strict figure — the two numbers together are often the more useful pair, because their gap is the scope change.

Team-managed projects

Team-managed projects estimate in Story point estimate, not Story points. Use that field in every value row; for a dashboard over mixed boards, add one row per field and sum them in the formula.

Variations

History across sprints

Sprint Health Monitor's comparison layout also takes one board four times, on Current, Previous, 2 sprints ago and 3 sprints ago: four batteries, four strict say-do results side by side, rolling forward on their own. For a longer history the native Velocity chart remains the right tool. Suite shows one sprint at a time — the sprint chip flips to any past sprint — and does not draw a multi-sprint trend line of the ratio.

By issue count or time instead of points

Teams that don't estimate can run every setup above on issue count. Sprint Health Monitor takes any numeric field as its metric; in Suite, replace Sum of Story Points with Count or with Sum of Original estimate.

Planned vs. actual for a release or a quarter

The same Number formula works on a date-scoped Suite dashboard: scope the dashboard to a fix version or a JQL, set the time window to the quarter, and the formula compares delivered against planned points with the previous quarter in the badge. Without a sprint there is no "committed at start", so this is always the live reading.

Velocity chart vs. Sprint Health Monitor vs. Suite

Frequently asked questions

Have a variant of this setup that isn't covered here? Write to [email protected] — we answer fast, and good questions become new pages.