# Sprints

2026-08-11

Phase 4 of the issue tracker. The board shows what is being worked on; this is
about deciding what *will* be, and looking honestly at what happened.

## 🚨 The decision that shapes everything: a burndown cannot be computed later

The obvious implementation asks the database, today, how many points remain and
draws a line. It is wrong, and it is wrong in a way nobody notices until the
chart is being used to make a decision.

"How many points were left on day three" cannot be recovered from the current
state, because between then and now:

- issues were added to the sprint and taken out of it
- story points were changed
- issues were closed and reopened
- issues were deleted

A chart drawn from today's rows shows a sprint that never happened — usually a
tidier one, because scope added late looks like scope that was always there.
That is the failure mode: it does not look broken, it looks *good*.

So **a burndown is a series of snapshots, written as the sprint runs.** One row
per sprint per day, holding the totals as they stood. Once written a snapshot is
never recalculated; it is what was true that day, and a chart that changes when
you look at it again is not evidence of anything.

🚨 **The snapshot is queued work, never a page view.** Both because the standing
rule forbids that kind of work in a visitor's request — it took a live site down
once — and because a snapshot written when somebody happens to open a page is a
snapshot with holes on the days nobody did.

## Velocity is measured once, at the end

Velocity is the completed points of a finished sprint. It is **stamped onto the
sprint when it completes**, not recomputed from its issues afterwards.

Recomputing means an issue reopened next month silently lowers a velocity from
two months ago — and velocity is used to plan, so a number that changes behind
you is worse than no number.

## Completing a sprint has to ask about what did not get done

A sprint ends with unfinished work in it. There are exactly three honest things
to do with it, and the person completing the sprint has to choose:

- move it to the next sprint
- put it back in the backlog
- leave it in this sprint

🚨 **No default.** Jira picks one; picking one here means the choice gets made by
whoever wrote this file rather than by the team, and the wrong choice quietly
rewrites what the sprint report says. The screen asks, and will not complete
until it has an answer.

## One active sprint at a time

Jira allows several in parallel and it is the source of a great deal of
confusion — "which sprint is this in" stops having one answer, and a burndown
over overlapping sprints is not a chart of anything.

Convoro allows one active sprint per project. Where a team genuinely needs
parallel streams, those are two projects, and everything else in the tracker
already agrees with that.

## Points are not estimates

`story_points` is the Scrum unit; `original_estimate` and `time_spent` are
seconds. They answer different questions — relative size against elapsed hours —
and a burndown that silently mixed them would be a chart with two units.

Burndown is by points, with a count of issues alongside for the teams that do
not use points at all. 🚨 **A sprint of unpointed issues gets a count-based
burndown rather than a flat line at zero**, which is what "burn down the points"
would produce and would read as a sprint where nothing happened.

## The backlog

Everything in the project that is not done and not in a sprint, in `board_rank`
order — the same decimal ordering the board already uses, so dragging an issue
from backlog to sprint and back does not renumber anything.

## What this phase does not do

- **Epics and a roadmap.** The model has `parent_id`; the timeline view that
  makes it worth showing is its own piece of work.
- **Sprint goals as a tracked thing.** A sprint has a goal field; measuring
  against it is a judgement, not a number.
- **Capacity planning.** Hours per person per sprint is a scheduling product,
  and the tracker is not one.

## Not matched, deliberately

- **Parallel sprints**, above.
- **Sprint permissions.** Who may start and complete a sprint is who may move
  cards on the board. A third permission over the same work is a third answer
  to one question.
