MOTIR-1285 · Burndown: a sprint entered with already-DONE items keeps their points in the remaining line — the chart never burns down to the actual remaining (check Jira + Linear)

MOTIR-1285Done

Burndown: a sprint entered with already-DONE items keeps their points in the remaining line — the chart never burns down to the actual remaining (check Jira + Linear)

Reported by Yue. The sprint burndown chart doesn't reconcile with the actual remaining when the sprint was entered with already-done items.

Symptom

Sprint total story points 322; 303 completed; actual remaining = 19 (the scrum header / sprint-report number).
The burndown chart starts at 72 — the sprint was entered with ~250 points already done, so the remaining-at-start was 72 (not the full 322).
But the chart's CURRENT remaining shows 40+, while the actual remaining is 19 — ~21 points are stuck in the line and never burn down.

Likely root cause

reportsService.getBurndownSeries reconstructs the remaining line from the immutable committed baseline ± the work_item_revision deltas (workItemRevisionRepository.aggregateSprintBurndownByDay: a completion burns it DOWN, a scope-add raises it UP). An item that is already done when it enters the sprint (done at start, or a done item added mid-sprint) contributes a scope-add (+points) but has NO offsetting completion event inside the sprint window (it completed before joining the sprint), so its points raise the remaining line and are never burned back down — inflating the current remaining by ≈ the already-done points (40 − 19 ≈ 21). The end-of-series pinning to rollupForSprint().remaining (which is the correct 19) is not reconciling the drawn line.

(The start-at-72 itself is likely correct — Jira's remaining-burndown starts at the not-done work at sprint start — VERIFY; the real defect is the line not descending to the actual 19.)

Expected — VERIFY against Jira AND Linear (Yue)

Remaining at any time = the points of NOT-done scope at that time (a STATUS-AWARE reconstruction): a done item contributes 0 to remaining regardless of when/how it joined the sprint, so adding an already-done item must NOT raise the line.
The drawn line's current/last value MUST equal the actual remaining (rollupForSprint().remaining = 19) — the chart and the scrum-header / sprint-report number always agree (the DTO already claims this pinning; it's not holding here).
Jira: the burndown "Remaining" reflects the remaining estimate of the sprint scope; a done issue counts 0; scope changes adjust the line but a done item adds nothing to remaining. Linear: the cycle scope/burndown tracks scope vs completed; completed issues are not "remaining." Confirm the exact handling of a done-at-start / done-on-add item in BOTH before fixing.

Where

lib/services/reportsService.ts — getBurndownSeries (committed baseline + the remaining reconstruction + the rollupForSprint end-pinning).
lib/repositories/workItemRevisionRepository.ts — aggregateSprintBurndownByDay (the per-day raise/burn deltas; the scope-add of an already-done item is the suspect — it should net zero, not raise).
lib/dto/reports.ts — BurndownSeriesDto (committed baseline + reconstructed remaining).
Tests: 4.6.7 / MOTIR-255 (the burndown-series revision-trail tests) — add the already-done-on-entry + done-added-mid-sprint cases.

Acceptance (once fixed)

A sprint containing items already done at start (and a done item added mid-sprint) draws a remaining line that (a) keeps those points OUT of remaining and (b) ends at the actual rollupForSprint().remaining.
The fix matches the verified Jira/Linear behaviour; the burndown never disagrees with the numeric remaining.