Iteration burndown distorted by late scope and carryover
Team of nine runs two-week iterations. At iteration start, 26 issues are assigned, total weight 61. On day 4, the product manager adds 9 issues (weight 18) for a customer escalation that cannot wait. On day 7, four issues are moved to the next iteration without changing labels. The burndown chart is flat for days 1-3, drops vertically on day 4, then declines slowly and ends above zero on day 14. The team says the chart is wrong. The scrum master needs a one-page explanation for the steering committee and a fix that does not require new tooling. The group already uses iterations, issue weights, and a carryover label inconsistently. The committee cares about predictability: 7 of the last 9 iterations missed committed scope. The team also has 3 issues that are blocked by an external vendor and 2 issues that are split into smaller tasks after the iteration starts but not re-weighted.
1. Explain why the burndown is flat for three days, drops on day 4, and ends above zero. Which parts are chart mechanics and which are process/data problems?
Read the worked answer
Burndown is based on remaining open issue weight at the end of each day. Days 1-3 look flat because no issues were closed and no scope changed; the team was working, but the chart measures completed scope, not effort. The day-4 vertical movement is scope added: 9 issues and 18 weight entered the iteration, so remaining scope jumped up, not down. The final above-zero point means the starting-equivalent weight was 61 + 18 = 79, minus closed weight, minus four issues moved out. If moved issues were not labeled carryover and not removed from the iteration, the chart can still count them or the move can look like a drop. The chart is not wrong; it is reflecting late scope and inconsistent movement. Process problems: scope added after commitment, carryover not labeled, blocked and split issues not re-weighted. Fix data before blaming the chart.
2. Recommend three changes to iteration data hygiene that improve predictability without new tooling.
Read the worked answer
- Freeze a commitment baseline: at iteration start, record the list and total weight in the iteration description or a pinned issue; mid-iteration additions go to the next iteration unless the committee explicitly trades scope out. 2) Use scoped labels or a required
carryoverlabel; when moving an issue, remove it from the iteration and applycarryover, so the burndown and velocity reflect the decision. 3) Re-weight splits and blocked work: if an issue is split, close the parent and create child issues with weights; mark blocked issues with ablockedlabel and do not count them as committed until unblocked. Also require every issue to have a weight before it enters the iteration; unweighted issues distort the chart. For predictability, compare committed weight vs completed weight, and track scope added per iteration as a separate number. These are configuration and discipline changes, not new tools.
3. How should the scrum master explain the mid-iteration scope change to the steering committee?
Read the worked answer
Present it as a trade-off, not an excuse: We committed 61 weight. On day 4 we added 18 weight for a customer escalation. We did not remove equivalent scope, so the iteration was over-committed by 18 weight. Four issues were moved out on day 7 and labeled carryover. The burndown jump is the scope addition. Show four numbers: committed weight, added weight, completed weight, and carryover count. State the decision rule going forward: emergencies are allowed, but they require an explicit swap or a documented exception, and the committee sees the added weight in the next report. Avoid saying the chart is wrong; say the data now shows the change. Ask the committee to approve the rule that mid-iteration additions are either swapped or reported as a scope change, so predictability is measured against a stable baseline.