Board reports

Three numbers about the selected sprint, and all three are story points: the large figure is the sum of points, the small one after the label is the number of cards. An unestimated card adds 0 points but one card. “Done” here means closed either way — completed and cancelled alike (throughput counts the same way, velocity does not). Cards only: a subtask carries no points. This is a snapshot of what the sprint holds now, not of the plan it opened with — a card added yesterday is already in “Total”. There is deliberately no completion percentage: a sprint closes when its cards run out, not on a date.

The vertical axis is how many points the sprint still has open, the horizontal one its days. The solid line is built from daily snapshots (a cron writes them for active sprints) plus a single point for today, computed live while today has not been snapshotted yet — so history is never rewritten: changing a past day takes a new snapshot. The dashed line is an even descent from the total at the first snapshot down to zero; it is a ruler, not a plan — nothing here is steered by the date, so drifting off it breaks no promise. What the chart does not say is why the remainder is not falling: a card split into two pushes the line back up.

Completed sprints only, oldest to newest. The grey bar is committed: the points of every card the sprint holds NOW, not the ones it opened with — a card added mid-sprint lands here too. The green bar is completed: the points of cards in a done status. A cancelled card stays in the grey bar and never reaches the green one, which is why the ratio can sit below 100% on a sprint everyone considers finished. Cards only, never subtasks. What velocity does not do is forecast. It calibrates the scale — it says whether a point still means what it used to — and only over sprints whose estimates were made BEFORE the work: a point derived from how long the work took cannot be tested against how long the work took. And velocity is a sum over sprints, so a card closed outside one is invisible to it: the line under the bars says how many that is, and disappears when there are none.

How many cards each completed sprint closed — closed either way, completed and cancelled alike (as in the tiles above, unlike velocity). The second figure divides that by the sprint's own length in whole calendar days and multiplies by 7: sprints here have run 14, 10 and 5 days, and without that the five-day one would read as the slowest. It is the number worth reading, because the completed/committed ratio above runs into a ceiling: a sprint closes when its cards run out, not on a date. What it does not measure is size — five one-point cards outweigh a single eight-pointer here.

Two different answers. Lead time is from the card being filed to it being closed, including every day it sat in the backlog. Cycle time is how long the work itself ran, from the first move into an active status. The gap between them is the queue. Median and p85 rather than a mean: one card that waited half a year would drag a mean somewhere no card has ever been — the median says what a card normally takes, p85 what you can promise. The moment work started is stored nowhere on the card; it is recovered from the card's own log — the first entry changing its status to one marked active. So a card closed before that log existed shows up under lead time and not under cycle time; the line below says how many finished cards do have a start on record. Cards with no completion date are out of scope entirely, and so are subtasks: a subtask's duration is its card's.

Does a story point still buy what it bought a month ago. Velocity can only answer that over sprints estimated BEFORE the work, and few of this board's cards were. So this asks the cards instead: every card carrying both an estimate and a logged cost, grouped by the estimate it was given. Two medians per size, with p85 under each — tokens and minutes side by side, since they measure different things and disagree. The bar is the median of whichever measure the board has: tokens where any card carries them, minutes otherwise. The card count on the right is the number to read first: a size backed by fewer than five cards is greyed and left out of the verdict entirely, because a median over three cards is an anecdote. Beside every size the report prints the step from the size above it as a percentage, and marks it “within noise” when that step came out smaller than the spread inside the two sizes themselves (p85 against median). That mark is the point of the column: a rise of a quarter between two sizes whose own cards range twice as far apart is not evidence that the two estimates bought different amounts of work. The verdict says the same in a sentence — “rises but does not separate”, naming the pairs that stuck together — and it is read from tokens alone wherever any card carries them; claimed time sits beside them and never enters it, because a claimed minute measures how long a session ran, not how much work it held. What the report cannot tell you is why a size drifted — a scale that stopped meaning what it meant and a month of unusually gnarly cards look identical here. Cards only, never subtasks.

How many cards sit in each status — the whole board, or one sprint when one is selected above. It counts cards, not points and not subtasks: an eight-point card weighs the same here as a one-pointer. The statuses are keys from this board's own dictionary, so which bars exist depends on which statuses the board defines. What it does not say is time: a card that has sat in a status for three weeks and one that entered it an hour ago look identical here.

The same cards as above, cut by label — the one dimension this board records richly and neither status nor priority says anything about: bugs against features, security against UX, what tech-debt actually ate. Two numbers per row, because they disagree: the bar and the first figure are story points, the second is the card count. A dozen one-point chores and three eight-point features draw the same bar in a card count and nothing alike in effort. Rows are ordered by points, heaviest first, since the ordering is the finding. Labels overlap by design (two to five to a card here), so the rows add up to more than the number of cards — that is not an error to correct: a row says how much went into that label, not what share of the whole it is. Read the unlabelled line first: a cut over labels says nothing about the cards that carry none. Cards only, never subtasks, within the sprint selected above. Click a row to filter the board itself by that label.

What the work on this board cost — from the cost entries on its cards, not from anything measured. The minutes are CLAIMED: a person types them in, and focus sessions deliberately never feed this — they measure time inside the widget, which is a different answer. Tokens are typed in the same way, with one exception: a finished agent run adds its own tokens once, credited to the agent's owner. The date range filters when the work happened rather than when it was written down, so an entry made on Friday for Tuesday's work belongs to Tuesday. The “Cards” tile counts the distinct cards carrying at least one entry, not the cards on the board. The sprint selected at the top of the dialog narrows this report too.