A sprint is a time-boxed container for work. Where a plan decomposes one feature, a sprint organises what a team is doing over a period.
They are not alternatives. A sprint can contain tasks belonging to several plans, and a plan can span several sprints.
What a sprint gives you
- a defined period with work assigned to it
- metrics on what was delivered against what was planned
- a timeline of how it progressed
- settings scoped to the sprint
Metrics
The metrics view answers what actually happened versus what was intended.
The numbers worth attention:
- Completed against committed. Consistently under-delivering usually means over-committing, not under-performing.
- Rework rate. Rising rework points at specification quality rather than execution — see Specifications.
- Queue time. Work sitting in
PENDINGis a capacity signal, not a planning one.
That last distinction matters. A sprint that under-delivered because tasks queued for days has a capacity problem; the same shortfall because tasks kept returning as rework has a specification problem. The fixes are unrelated.
Timeline
Shows how the sprint progressed rather than just where it ended. A sprint that delivered everything in the final two days behaved very differently from one that delivered steadily, even though the totals match.
With autonomous execution the shape is often driven by capacity: work queues until slots free, then several things complete together.
Sprints and capacity
A sprint does not reserve capacity. Its tasks compete in the same queue as everything else, ordered by priority.
If sprint work needs to take precedence over background automation, set its priority accordingly — and give scheduled and Sentinel work a lower priority. See Capacity and agent slots.
When not to use one
If you are not running a time-boxed process, you do not need sprints. Plans handle decomposition and lanes handle parallelism; sprints only add value if the period itself is a unit you plan and report against.