FTE-months: a capacity unit you can defend in a budget meeting

Story points work. That is not the argument. They work for the thing they were designed for: a single team, sizing a single backlog, over a horizon of weeks, calibrated against its own history.

The trouble starts when that number is asked to travel — up to a portfolio view, across to another team, or sideways into a budget conversation. It does not survive any of those journeys, and everyone involved quietly knows it, which is why the numbers get re-derived on a whiteboard before the meeting where they matter.

What an FTE-month is

One full-time person working for one month. That is the entire definition.

A demand that needs two backend engineers for six weeks is roughly three FTE-months. A demand that needs one designer for two weeks is roughly half an FTE-month. The unit is coarse on purpose, and the coarseness is the feature, not a limitation to be refined away later.

Three properties story points don't have

It is comparable across teams. A story point is explicitly team-local — that is in the original definition, and anyone who has tried to sum points across teams has produced a number with no meaning. An FTE-month means the same thing everywhere, because a month is a month and a person is a person. You can add them up across five teams and the total is real.

It converts to money in one multiplication. FTE-months times a monthly cost figure gives you a forecast. That is the number leadership is actually asking for when they ask how big something is; "34 points" cannot be converted into it by anyone, at any time, using any method. This is why the conversion always ends up happening informally, in someone's head, badly.

It is honest about its own precision. Nobody looks at "3 FTE-months" and believes it is accurate to the day. The unit's granularity broadcasts its own error bar. "34 story points", by contrast, has two significant figures and invites exactly the false precision that makes commitment conversations go wrong — the difference between 34 and 38 will be discussed as though it means something.

The altitude argument

These are different jobs at different altitudes, and the mistake is using one instrument for both.

Sprint altitude — one team, two weeks, known people, known codebase. Here relative sizing genuinely beats absolute time estimates, because the team's own history calibrates it and nobody outside needs to read the number. Keep story points. They are good at this.

Commitment altitude — several teams, one to two quarters, a promise being made to someone outside engineering, a budget attached. Here you need a unit that crosses team boundaries and converts to cost. Relative sizing cannot do either.

Trying to run the commitment altitude on story points means either summing incomparable numbers or maintaining a conversion table that everyone treats as fiction. Trying to run the sprint altitude on FTE-months means pretending to a precision the unit does not have. Use both, at the altitudes they fit.

How to estimate one without ceremony

The estimate is deliberately cheap. For each team that has to do something:

• How many people, roughly, at what fraction of their time?
• For how many weeks?
• Multiply, divide by four, round to the nearest quarter.

Two backend engineers at half time for eight weeks is 2 × 0.5 × 8 ÷ 4 = 2 FTE-months. The whole exercise takes a couple of minutes per team, which is the correct amount of time to spend on a number that is going to be wrong by thirty percent regardless.

Two rules make it usable. First, the team that will do the work gives the number. An estimate produced by someone else is a wish, and the gap between the wish and the estimate is precisely the amount by which the commitment will slip. Second, record the confidence alongside it. "3 FTE-months, low confidence" is a genuinely different input to a commitment decision than "3 FTE-months, high confidence", and collapsing them into one number throws away the more important half.

The objection worth taking seriously

A fair pushback: an FTE-month treats all people as interchangeable, and they are not. The one person who knows the legacy billing system is not substitutable with a headcount.

That is true, and it is why capacity should be estimated per craft or per team rather than as a single organisational pool. Three FTE-months of backend and one of design is a usable statement. Four FTE-months of undifferentiated "engineering" is not, because it hides exactly the constraint that will bite. The unit is fine; the aggregation is where the information gets destroyed.

The genuinely irreplaceable-person problem is not a capacity-unit problem at all. It is a key-person risk, and it belongs in the risk list where someone has to look at it, not buried inside a number.

What this looks like in practice

In DeliverySheet, capacity on a demand is recorded per craft: which craft, which team lead, how many FTE-months, and how confident they are. The total is derived from the rows rather than typed, so the headline figure cannot disagree with its own breakdown — and when a commitment is re-baselined, the capacity is re-agreed per team rather than adjusted centrally.

Deliberately absent: story points, velocity, burndown charts, and any notion of hours. Those belong to sprint altitude and to tools built for it. What I care about is whether a promise made in a planning meeting had a defensible number behind it, and whether the people who have to deliver it ever agreed to that number.