Sprint commitment: how the number is calculated

Sprint commitment, also called say/do, measures how much of the original sprint plan was completed by the sprint’s closing time. Issues are the default measurement; historical story points are available when configured. All results describe team work.

Say/do = completed issues from the original plan ÷ issues in the original plan.

The plan is fixed at the original sprint start. There is no grace window. A planned issue that leaves and returns stays in the plan. Removing a planned issue does not reduce the denominator. Work added after the start is shown separately and never increases say/do.

Done follows the app’s status-category and resolution rules, evaluated at sprint close. Edits after close do not silently rewrite a published snapshot.

Sub-tasks are not counted on their own: Jira’s sprint search and sprint report treat them through their parent, and the app reads sprint membership from that search.

Example

A sprint starts with 10 issues. Six planned issues finish; four planned issues are removed. Three more issues are added after the start and all three finish.

• Say/do is 6/10 = 60%.
• Removed from the original plan: 4, still in the denominator.
• Added after start: 3, of which completed: 3, outside the ratio.

An empty original plan has no percentage: the app shows “no original plan”. A real zero means there was a plan but none of it was confirmed done. A missing snapshot, access denial or error does not become a zero.

Partial history

Historical imports may not recover every event. The snapshot explains that limitation. Issues with unknown membership history are excluded from counts because the app cannot place them reliably. Planned issues with an unknown outcome remain in the denominator and do not count as completed. The partial label is essential when interpreting that ratio.

Deleted issues and facts that were never recorded may not be recoverable. Changing sprint dates does not silently move an observed original plan to the new start date.

Comparing periods

The comparison uses the previous available published snapshot for the same team. There may be missing periods between them. Differences are percentage points: 6/10 to 8/10 is +20 percentage points, shown on the dashboard as ”▲ 20 pts”. The details panel shows both n/N values beside the delta.

Different rule or formula versions cannot be compared. Old snapshots without recorded versions also have no delta. A previous partial snapshot remains labeled partial. Access must be confirmed for every issue in each period before its counts enter the comparison.

On the dashboard

The tile shows the say/do percentage, the change against the previous available snapshot (for example ”▲ 20 pts”), a bar of planned and added work, and a line such as “6 of 10 planned done · 3 added”.

The Sprint commitment section shows “Plan against finished work, by kind of work”. Its headline is the say/do percentage with the change against the previous sprint.

• … · rows by kind of work: one row per kind of work and a final All work row. Segments show Done, In progress, Not started and Added after start, and when present Done status, no resolution, Unknown end state and Not done, state not saved; the marker Plan at sprint start shows where the original plan ends. Selecting a segment lists its saved issues.
• Trend by sprint · done by kind of work, say/do on top: the outlined column is the sprint you are looking at; selecting another column chooses that sprint.

The How we count caption repeats the rule: done means the Done status category plus a resolution, and work added later never raises say/do. Issues that match no kind of work are shown as Unclassified.

Selecting the section title opens Sprint commitment details with the explanation, the category chart, story points, Flagged and carryover. The sliders button opens Sprint commitment settings with Work categories, Blocked work · Flagged settings and Story-point field.

Snapshots and the gadget

Anyone who can see a Scrum board creates a team for it and chooses that board. The app starts preparation for one latest valid closed sprint and selects it. An existing snapshot can be published for the team without reconstructing history.

A pending first result is checked automatically for up to two minutes. While the sprint has no snapshot, the section shows Check again and, for users who can see the board, Prepare snapshot. A failed queue submission is recoverable in the background; this can take longer than two minutes. Boards without a valid closed sprint wait for one.

Choose a closed sprint in the dashboard header; the URL keeps the selected team and period. In a Jira dashboard, add “QA Metrics — Sprint commitment” and configure its team, sprint and title. The gadget reads the same published data and applies the same access checks.

“Not shown” means the app could not prove access to the entire snapshot. It reveals neither the aggregate nor how many issues are hidden. A comparison can be unavailable while the independently authorized current result remains visible.

The details panel and the gadget provide a selected-sprint view and a trend, with saved category breakdowns. Gadget settings keep Measurement and Default view; temporary switches do not change those defaults.

Above the chart in the details panel, one line repeats the sprint in numbers: planned, done with the say/do percentage, added (+) and of which done, removed (−), scope change as (added + removed) ÷ planned, blocked at close and carryover.

An input the period does not have, such as Flagged detail or carryover, is named as unavailable or not saved; it is never shown as zero.

Work categories

In guided setup, the first rule step sets categories from a starting point and checks them on the last closed sprint (see Guided setup). Later, open Sprint commitment settings and expand Work categories. Anyone who can see the board can load its settings, add named categories, and save.

Every condition in a group must match; alternative groups are joined by OR. Conditions can use an exact label, component, issue type or project. The project is the one the issue was in when its sprint closed; periods closed before this option existed show it as unknown.

The optional QA preset uses qa:automation, qa:internal, and qa:ai. Saving rules does not add labels to issues.

Categories use field values recorded at sprint close and the rules effective at that close. Changing settings later leaves saved periods unchanged. If several categories match, the issue is Unclassified with an explanation.

An other category from guided setup applies only when no other category matched. Unknown historical fields and periods before configuration are shown explicitly; they are not assumed to have empty values.

The dashboard section calls categories “kinds of work” and ends with All work. The category chart in Sprint commitment details separates completed original-plan work, completed added work, and work not counted as done.

Its Percent mode divides completion by all known work in that category. The headline say/do continues to use only the original plan. Select a row or segment to inspect its saved issues and categories. Unknown membership is excluded from bars and reported separately.

Under the rows, Open work outside categories names the issues no rule matched that were not done at close, so nothing is lost silently. Original-plan work removed before close is marked (removed) because it stays in the plan; Show issues opens the same saved rows.

Flagged work is shown as a count per row and in Blocked work at close, not as a bar segment: a flagged issue also has a status, and the bar must add up to the row’s work exactly once.

In the trend, Count includes original and added completion; Percent includes only completed original work divided by the full original plan. Open Category counts for textual values. Changed category rules and unavailable historical breakdowns are labelled.

Choosing Component or Issue type in a condition loads the Jira values automatically. On a board with one project the values come from that project; on a board with several projects, choose the project to browse first.

Select a value by its current Jira name; the rule keeps its stable ID. The project selector only chooses which values to browse and does not add a project condition.

You can browse another project without losing your draft. A missing or inaccessible current value is marked kept and is never silently replaced. Reloading saved settings explicitly replaces the draft with the last saved version.

Each field supports up to 500 choices and a board up to 100 projects. Unavailable or incomplete metadata is reported separately from an empty list. Existing conditions can be kept even when their current names cannot be loaded.

Renaming a component or type does not change its ID or reclassify an already published sprint.

Historical state and blocked work

New snapshots show the state at close: Done, In progress, To do, Done without resolution, or Unknown. Status-category metadata is frozen when the period is first calculated; Jira does not provide earlier administrator changes to status categories. The collection date is shown.

Anyone who can see a Scrum board can enable Blocked work · Flagged settings in Sprint commitment settings, using Jira’s built-in Flagged field and a visible work item already flagged through the board’s Add flag action.

Settings apply to all teams in this installation. Later changes affect future closes. Existing periods without saved detail stay unavailable, including closes before configuration.

Flagged is independent of Done. For example, one Done issue and one In progress issue can both be flagged: say/do is 1/2 = 50%, while Flagged at close is 2.

Counts include original and added work; unresolved membership is excluded and reported. Select the total or a category’s Flagged count for its exact saved issues. Unknown flag history is shown separately from confirmed No.

The issue list shows elapsed calendar hours flagged within the sprint window, starting no earlier than issue creation. This is neither working time nor time specifically spent as a sprint member. A later removal does not erase the flag or duration saved at close.

Unsupported or incomplete history yields Unknown; a known close flag can have an unknown earlier duration. Changing the sprint’s close after its binding was frozen leaves Flagged unavailable for that changed cutoff. Such uncertainty does not change the say/do completion formula.

Carryover

New snapshots identify original or added work that also participated in the previous sprint and was not Done at that earlier close. Current completion does not erase this history.

For example, one unfinished issue in Sprint A, carried into Sprint B and completed there, contributes one carryover in B. Removed original work still participated under the fixed-plan rules; carryover does not require Jira to have moved the issue automatically.

The comparison uses a frozen source generation. Its sprint ID, revision and the time its board chronology was observed are shown beside the count. Later revisions of the source do not silently change the saved result.

The collector checks dates, missing known periods and overlapping sprints; it never skips a missing predecessor snapshot to pick an older available one. Jira cannot supply deleted or never-visible history, so the observation cannot prove all past sprints. A missing or ambiguous predecessor shows Unknown, including the first observed period.

Select the carryover or unknown count for the exact saved issues. Unresolved membership is excluded and counted separately.

Access to the previous sprint and every saved source member is checked again when you open the result; if it cannot be verified, carryover is hidden while an independently authorized current sprint can remain visible.

Older snapshots have no invented carryover detail. Changing a period’s original dates after its source was pinned gives unknown carryover for the changed window and does not change the say/do formula.

Story points

Anyone who can see the team’s board opens Story-point field in Sprint commitment settings, selects an existing numeric estimate field and confirms the binding for the board. The app does not create Jira fields.

Settings take effect from their saved time. Older snapshots do not receive invented estimates; a field configured after a sprint started is not applied to that sprint’s original plan.

Original-plan estimates are frozen at the original start. Added work uses its estimate at first entry after start. Removing a planned issue keeps its weight, and reestimation does not change historical scope.

Say/do in points is completed original-plan points divided by original-plan points. Added completion remains outside that ratio.

For example, start with issues worth 3, 5 and 0 points. Complete the first and third, remove the second, then add and complete an 8-point issue. Say/do is 3/8 = 37.5% in points, or 2/3 in issues.

The removed issue still contributes five planned points. Completed added work contributes eight points to throughput. Changing current estimates to 34 and 55 after close leaves the saved weights at 3 and 8.

A known zero is different from an unestimated issue or unknown history. Missing estimates are listed beside known subtotals. An incomplete or zero-point original plan has no percentage; missing added estimates do not turn a fully proven original-plan ratio into zero.

The point delta requires complete, comparable periods with the same field, settings and formula.

Total and the original-plan line

The category chart in Sprint commitment details ends with Total, including original and added work. In the example above it shows 3 of 4 issues or 11 of 16 points completed.

Its Percent mode is 75% or 68.75%, respectively, rounded on screen. These are completion shares of all sprint work; the headline say/do still uses only the original plan.

The dashed line marks that original plan: three issues or eight historical points, including removed work. In this chart blue marks completed added work; the dashboard section shows added work as Added after start in purple.

A segment beyond the line can contain unfinished work; position alone does not mean it was completed. Partial snapshots or point data suppress the target line with a reason. Empty totals have no percentage or drawn line.

Select Total or a segment for its saved rows. Zero-point issues remain accessible through the row label and the matching completion segment even though zero has no visible bar width.

The trend still counts only completed work: three issues or eleven points in this example; its Percent mode uses original-plan say/do, not Total completion.