Topic
Capacity and what to measure
The short answer
Size commitment-level work in FTE-months, one full-time person for one month, because that unit is comparable across teams, converts to cost in a single multiplication, and is coarse enough that nobody pretends it is precise. Story points do none of those three and are deliberately team-local. Then measure allocation, meaning who is committed to what at what size and what is overdue, and not consumption, meaning hours logged, per-person completion rates or velocity. Allocation answers the questions a manager is accountable for and stays accurate when watched; consumption stops being accurate the moment people know it is being read.
Two questions get asked of every delivery organisation, usually by people outside it: how big is this, and what is everyone working on. Both have well-known answers that fail in the same way — they are precise, they are measurable, and they stop being true the moment anyone acts on them.
Size in a unit that travels
Story points work for what they were designed for: one team, one backlog, calibrated against its own history over a horizon of weeks. They fail the moment the number has to travel — up to a portfolio, across to another team, or sideways into a budget conversation. They are deliberately team-local, so summing them is meaningless; they have no monetary meaning, so nobody can convert them; and two significant figures invite an argument about the difference between 34 and 38 that the estimate cannot support.
An FTE-month — one full-time person for one month — travels. It is comparable across teams because a month is a month, it becomes a cost forecast in one multiplication, and its coarseness broadcasts its own error bar. Use both, at the altitudes they fit: relative sizing inside a sprint, FTE-months at the altitude where a promise is being made to someone outside engineering.
Measure allocation, not consumption
Allocation is what people are committed to. Consumption is what they spent. Every decision a delivery manager is actually accountable for — can we take this on, what breaks if we do, who is overloaded, what is late and what does it block — is answerable from allocation alone.
Consumption data is worse than unnecessary. Completion rate measures the assignment, not the person. Velocity is a function of estimate inflation and self-corrects in the wrong direction. And the decisive property: allocation stays accurate when it is watched, because being honest about your load is how you avoid being given more, while consumption stops being accurate the moment people know it is being read.
The full argument
Sizing work in units that survive a budget meeting, and measuring allocation instead of surveillance.
- When a team is over-committed, say which thing slips
The honest response to too much work is not more effort or a re-estimate. It is naming which commitment moves, and telling the person who was promised it.
- Estimating capacity when you don't know enough yet
The honest answers to "how big is this?" are a range, a range with low confidence, and "I need to look first" — and only one of those is usually allowed.
- Allocation, not consumption: what an engineering manager should measure
The case for measuring what people are committed to rather than what they spend their hours on — and why the second one degrades the first.
- FTE-months: a capacity unit you can defend in a budget meeting
Story points do not survive contact with finance. FTE-months are coarse, boring, and convert directly into the two answers leadership asks for.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.