Development Velocity
We measure development throughput in story points and track it through velocity and burndown. Because we can quantify it, we can spot bottlenecks and improve delivery predictability over time.
Story points - our unit of complexity
Section titled “Story points - our unit of complexity”A story point measures the complexity and effort of a feature, bug, or requirement - not raw hours. We estimate in points because complexity is more stable and comparable across people than time estimates.
- Points are assigned during refinement and confirmed at Sprint Planning, AI-assisted then human-decided (see Project Manager).
- We use a Fibonacci-style scale (1, 2, 3, 5, 8, 13) - the gaps force a deliberate “is this really bigger?” conversation.
- An item larger than ~13 points is split before it enters a sprint.
| Points | Rough meaning |
|---|---|
| 1–2 | Trivial / well-understood, low risk |
| 3–5 | Normal story, some unknowns |
| 8 | Complex, multiple components or notable risk |
| 13 | Large - split if possible before committing |
Velocity - points completed per sprint
Section titled “Velocity - points completed per sprint”Velocity is the sum of story points for items that reach “Done” in a sprint. Averaged over the last 3–6 sprints, it becomes our forecasting baseline for how much to commit to next.
xychart-beta
title "Team velocity (points completed per sprint)"
x-axis [S1, S2, S3, S4, S5, S6]
y-axis "Story points" 0 --> 45
bar [28, 31, 30, 35, 33, 38]
We watch the trend, not any single sprint: a steady or rising average with low variance signals a healthy, predictable team.
Burndown - progress within a sprint
Section titled “Burndown - progress within a sprint”The burndown tracks remaining points against the ideal trajectory, day by day. It is the team’s early-warning system: a flat line mid-sprint means work is stuck.
xychart-beta
title "Sprint burndown (remaining story points)"
x-axis [D1, D2, D3, D4, D5, D6, D7, D8, D9, D10]
y-axis "Remaining points" 0 --> 40
line [40, 36, 32, 28, 24, 20, 16, 12, 8, 0]
line [40, 38, 36, 31, 30, 22, 18, 11, 5, 0]
The straight line is the ideal burn; the second is a typical actual. Persistent gaps above the ideal line are discussed at the Daily Scrum.
What we monitor
Section titled “What we monitor”| Metric | What it tells us | Healthy signal |
|---|---|---|
| Velocity (3–6 sprint avg) | Sustainable throughput | Stable or gently rising |
| Velocity variance | Predictability | Low and shrinking |
| Burndown shape | In-sprint flow | Tracks near the ideal line |
| Points per developer | Load balance & blockers | Even, no silent overload |
| Spillover (carried points) | Over-commitment / blockers | Low and trending down |
| Scope change mid-sprint | Goal protection | Rare; handled next sprint |
Closing the loop - improving velocity
Section titled “Closing the loop - improving velocity”Because velocity is measured, it is improvable. Typical levers we act on, decided at the Retrospective:
- Smaller stories → smoother burndown and fewer carryovers.
- Reducing spillover → more accurate commitment, less context-switching.
- Removing recurring blockers (environments, reviews, dependencies) surfaced by points-per-developer and burndown stalls.
- AI assistance in build and review compresses cycle time per point (see AI Tooling Map).
The goal is predictability first, speed second - a team that reliably hits its commitment is more valuable than one that is occasionally fast.