Last week's report showed part of the project completed; this week's percentage is lower despite new work being finished. Execution has not necessarily reversed: the scope being measured may have changed. Request a bridge between reports showing additions, removals and remaining work before judging the number.
A changing denominator needs explanation
Consider a fictional workshop-booking system with ten defined items, four of them closed. Two items are then added and one removed through identified approval, leaving eleven in scope. These educational counts illustrate scope movement, not equal effort, product value or a payment percentage.
A later percentage can differ because total scope changed while earlier completion remained intact. Completed work might also change through reopening or a revised state definition. These are separate events requiring explanations and references, rather than one upward or downward arrow.
Fix the comparison unit and date
Ask whether the report measures item counts, time estimates or team-specific points. Do not compare different units across weeks. Even with the same unit, splitting one item into smaller ones can change counts without representing progress or added value by itself.
Record extraction dates, scope versions and inclusion rules. A new display filter might remove an item without a decision to remove it from the project. Distinguish approved scope changes from presentation changes so unresolved work cannot disappear behind an unexplained filter.
A bridge table between reports
| Row | Record | Required reference |
|---|---|---|
| Starting scope | Included items and measurement unit | Previous report version and boundaries |
| Additions and removals | Separate movements during the period | Decision, date and approver |
| Ending scope | New comparison baseline | Clear relationship to changes |
| Completion movement | Closed and reopened work | State definition and item references |
The example reads ten, plus two, minus one, resulting in eleven. Show closing and reopening separately rather than include them in scope arithmetic. Ask the provider to explain differences that cannot be traced to references instead of manually adjusting a number to make the report appear consistent.
What can the chart tell you?
Jira's Burnup document describes separate scope and Done lines with alternative measurement units. This helps show increasing work alongside completion, but a tool's Done state does not independently prove deployment or customer acceptance. Its guideline is approximate rather than a guaranteed finish date.
If the team uses this report, examine settings, calculation boundaries and exclusions. If it uses another tool or spreadsheet, request the same principle without requiring Jira: separate work-volume changes from state changes. Do not convert points into cross-team productivity comparisons or automatic financial percentages.
An updated plan still needs change references
The Scrum Guide's Sprint Backlog sections describe a plan updated through learning and scope clarification with the Product Owner while preserving the goal. This explains changing planned work but does not define authority over contractual scope, pricing or amendments.
Ask the report to distinguish proposals awaiting decisions from approved additions. A team may discuss an alternative not yet committed for implementation; counting it as confirmed changes the apparent remaining work. Conversely, approved work should not disappear because information has not reached the report's preparer.
Use the report to support a decision
After explaining movements, identify what the project owner must decide: an addition, a conflict or a schedule review against the revised baseline. The sheet should not imply equal items or prediction from a line alone. Keep both versions so reviewers can reconstruct the difference later.
Consult change-request pricing for commercial impact and requirements before development for defining work. Attach a sample report and scope bridge when requesting custom software from Nextwave, agreeing on reporting that explains change rather than an unsupported number.
References
Relevant Jira Burnup interpretation and Scrum Guide 2020 plan sections were read on 4 November 2026. No actual report or methodology implementation is represented. Prepared with AI assistance and information and translation review.
