Estimation, Velocity, and the Definition of Done
Whatever method a team uses, it constantly faces two questions: how big is this work, and how much can we take on? Teams answer them with a few shared habits — estimating in rough relative sizes, tracking how much they finish, and agreeing in advance on what "finished" even means.
These habits sound dry, but they're where a lot of newcomer confusion lives — especially the strange-sounding "story points". Clearing them up makes a team's planning meetings suddenly make sense.
An everyday parallel: when you help someone move, you don't predict the exact minutes to carry each box. You size them small, medium, large — relative sizes — because comparing is far easier and more reliable than predicting a clock.
Why Relative, Not Hours
Humans are famously bad at predicting how long a task will take in hours, but surprisingly good at saying one task is "about twice as big as that one". So Agile teams mostly estimate in relative size, not time. It sidesteps the false precision of "this will take 6.5 hours" and captures what's actually knowable: how tasks compare to each other.
Story Points and T-Shirt Sizing
The two common scales are both relative. Story points give each piece of work a number — often from a sequence like 1, 2, 3, 5, 8 — where bigger means more effort, complexity, and uncertainty combined. T-shirt sizing is even simpler: small, medium, large, extra-large. Both deliberately avoid hours; a 5-point story is "bigger than a 2", not "five hours".
| Points | Feels like | A Cadence example |
|---|---|---|
| 1 | Trivial, well understood | Change a button's label |
| 2 | Small and clear | Let a user rename a habit |
| 5 | Substantial, some unknowns | Add daily reminders |
| 8 | Big or uncertain — maybe split it | Redesign the whole home screen |
Velocity
Velocity is how many points a team typically finishes in a sprint. If Cadence usually completes about 20 points per two-week sprint, that number helps them forecast: a 5-point story fits comfortably; 40 points of work is roughly two sprints. The vital caveat: velocity is a planning tool, not a scoreboard. Comparing one team's velocity to another's is meaningless (points are relative to each team), and pushing a team to "increase velocity" just makes them inflate their estimates. It forecasts; it doesn't grade.
Definition of Done and Ready
Finally, two shared checklists prevent endless arguments. The Definition of Done is the team's agreement on what "finished" means for any piece of work — not just "the code runs", but coded, reviewed, tested, and documented. The Definition of Ready is the mirror: what a piece of work needs before the team will start it (clear enough, small enough, with acceptance criteria). Together they stop the two classic disputes: "is this actually done?" and "is this even ready to build?"
On the Cadence team, the reminders story gets pointed a 5 — bigger than the 2-point "rename a habit", smaller than redesigning the home screen. Their velocity of about 20 says it fits this sprint. And it isn't "done" when Marcus's code runs; it's done when it's reviewed by Lena, tested by Nora, and documented — the team's agreed Definition of Done. Everyone knows the bar before they start.
- "A story point equals a fixed number of hours." Points are relative size — effort, complexity, and uncertainty combined — deliberately not a unit of time. A 5 is "bigger than a 2", not "five hours".
- "Higher velocity means a better team." Velocity is a forecasting tool, and points are relative to each team — so comparing or chasing velocity just inflates estimates. It predicts; it doesn't grade.
- "Done means the code runs." Done is the team's full agreed checklist — typically coded, reviewed, tested, and documented. "It runs on my machine" is nowhere near it.
- Story points and velocity are the rituals that most confuse newcomers in planning meetings — understanding them lets you take part instead of nodding along.
- Knowing velocity is for forecasting, not grading, protects you from a common and damaging misuse of it.
- The Definition of Done is a quiet but powerful idea: a shared bar for "finished" prevents half-built work from sneaking through as complete.
Knowledge Check
Why do Agile teams usually estimate in relative sizes rather than hours?
- People compare sizes far more reliably than they predict exact hours
- Because it lets the team avoid doing any estimating at all
- Because hour estimates are always perfectly accurate anyway
- Because a strict rule forbids the team from ever mentioning time at all
What is a story point?
- A relative measure of a task's size, not a number of hours
- A fixed and exact amount of time, such as precisely one working hour
- A score for how good or valuable a feature is
- The dollar cost of building a feature
What is velocity, and what is it for?
- The points a team usually finishes per sprint, used to forecast capacity
- A score to rank one team against another
- How quickly the finished software runs for users
- A target number the team should always be trying to push higher and higher
What does the "Definition of Done" establish?
- A shared agreement on what 'finished' really means for any work
- That the work is done as soon as the code runs once
- The order in which features should be built
- The conditions a task must meet before the team is allowed to start it
You got correct