Work management
Estimates
Points, minutes, or neither — which features consume which, and why a missing estimate is never zero.
A work item can carry a story point figure, a time estimate in minutes, both, or neither. They are not two spellings of the same thing, and several reports read one and ignore the other — so it is worth knowing which you are feeding.
| Story points | Time estimate | |
|---|---|---|
| Unit | A decimal, so half-points work | Minutes, like every duration here |
| Means | Relative size, a team's private scale | Wall-clock effort, comparable to a working week |
| Comparable between teams | No — and it is not meant to be | Yes |
| Read by | Burndown, velocity, initiative and release progress | Workload |
Why workload uses minutes and velocity uses points
Velocity compares a team against itself, which is exactly what a private relative scale is good for. Workload compares committed work against a person's available hours — and points cannot be measured against a working week, because nobody knows how many hours a five is.
A missing estimate is never zero
This is the rule every one of these features follows, and it is worth stating once because the alternative is quietly wrong everywhere.
- Initiative and release progress report percent by count *and* by points, always. Nine small items done with one large one left is 90% by count and perhaps 40% by effort, and either figure alone gets acted on wrongly.
- Progress is null, not 0%, for a bucket with nothing in it. Unmeasured is not *not started*, and a bar drawn empty says the work has not begun.
- The burndown reports how many items carry no estimate, so the points line can be read honestly. A sprint where nothing is estimated says so and shows item counts instead of drawing a line that means nothing.
- The cumulative flow diagram counts items, not points — an unestimated item crosses the board exactly as much as an estimated one.
- Velocity has no points figure for a team that does not estimate. Reporting zero would be false; the item count is reported instead.
- The workload grid marks unestimated items with `+n` beside the load. Without it, somebody carrying ten unestimated items looks completely free.
Which should you use?
- Points only
- The common choice for a product team. You get velocity, burndown and progress figures. The workload grid will show item counts but no load percentage, because it has no hours to compare against.
- Minutes only
- Sensible for an agency planning against client hours. You get a genuine workload picture. Burndown and velocity fall back to item counts, which for a team with evenly-sized work is often enough.
- Both
- Everything works. It is more estimating than most teams will keep up, and an estimate nobody maintains is worse than none — it is confidently wrong rather than obviously absent.
- Neither
- Entirely supported. Item counts carry the burndown, the flow diagram and velocity; the aging list and cycle time need no estimates at all and are arguably the more actionable reports anyway.
Estimates are never changed for you
Nothing in the product writes an estimate — not automation, not closing a sprint, not shipping a release. A figure on an item is one a person put there, which is what makes velocity mean anything.
Time estimates are not time recorded
The estimate is what somebody expected. Recorded time is what actually happened, and it lives on a separate record with its own lifecycle — it belongs to a person, is marked billable or not, and is locked by an invoice run. Neither is derived from the other, and the product deliberately does not compute a variance between them: that comparison is a management conversation, not a figure.