Capacity planning when one team serves several product lines

The question usually arrives as a headcount question: with three product lines and forty engineers, how many does each line get? It is the wrong unit. People do not sit in product lines. They sit in teams, and most organisations with more than one product line have at least a few teams that every line depends on. The plan fails or holds on those teams, and a headcount split never shows them.

This is the multi-line version of capacity planning for engineering teams. The four steps there still apply. What changes is who ranks the work, and where you look first.

Plan the teams. A product line is a queue

Capacity exists in one place: a team, for a period. A platform team of four has a certain number of FTE-months this quarter, and that number does not change with how many product lines would like some of it. A product line is something else: a list of requests with a person who cares about them. So the plan has two kinds of object and they should not be confused. Teams have a capacity line. Product lines have a queue. Planning is the act of walking the queues down the lines.

Which of three shapes are you?

• Dedicated teams. Each product line has its own teams and shares almost nothing. Each line plans alone, and this essay is mostly not about you. Check the exceptions: security review, data, release management.
• Shared teams. The same teams serve every line. There is one line per team and requests from all product lines compete on it directly.
• Mixed. Feature teams per product line, plus shared platform, data, design or QA. This is the common case and the hard one, because each line can produce a plan that fits its own teams and still be impossible, three times over, on the platform team.

The method, in five steps

1. Write down each team's real capacity for the period. Headcount times months, less support rotation, run-the-business work and a reserve for unplanned work. Do the shared teams first. They are the scarce ones.
2. Size every request per team, not per product line. "Line B's onboarding rework: 2 FTE-months web, 1.5 platform, 0.5 design", each with a confidence. A request that cannot be sized yet goes to a time-boxed discovery and stays out of the plan until it returns.
3. Rank across product lines, once, for each shared team. This is the step a multi-line organisation skips. Three ranked lists, one per product line, do not tell a platform team what to do first. One list does, and somebody above the product lines has to own it.
4. Walk each list down its team's line and stop when the line is spent. The first request past the line gets an answer, in writing: parked with a review date, declined with a reason, swapped in for something that is then visibly displaced, or committed early with a recorded exception.
5. Show each product line what it got. Its committed requests, and the ones that did not fit, each with the reason and the date it will be looked at again. A line that only hears about its yeses plans the next quarter on the assumption that everything else is still coming.

A worked example

Three product lines, A, B and C. Web (five people) and Mobile (three) take work from all three; Platform (four) is shared by everyone. A quarter is three months and each team holds back a fifth for support and unplanned work.

In total the organisation looks fine: 28.8 FTE-months of capacity against 33.5 requested, a gap that sounds negotiable. Team by team it is not. Web and Mobile fit. Platform is asked for 16 and has 9.6, so roughly two fifths of everything that needs platform work will not happen this quarter, whatever the product lines were told.

Now the ranking matters. Suppose the platform requests, in the order agreed across the lines, are: A's payment provider change (4), B's audit logging (3), C's single sign-on (3.5), A's reporting API (3), B's data export (2.5). Walking down: 4, then 7, and the third would reach 10.5 against a line of 9.6. A and B's first requests are in. C's single sign-on is the first one past the line, and it needs a decision: cut its scope to fit the remaining 2.6, displace something above it, or park it with a date. The last two are parked or declined. Then go back to Web and Mobile and remove the work that only made sense with the platform pieces that did not fit, because a front end for an API that is not being built is capacity spent on nothing.

Why a percentage split does not do this for you

"40% to A, 40% to B, 20% to C" feels like a capacity plan and is a budget. It is useful as a starting position and fails as the plan for three reasons.

• It is applied to the whole organisation and felt on one team. Twenty per cent of forty engineers is eight people. Twenty per cent of the platform team is 0.8 of a person, split across four heads. That is not capacity anyone can deliver with.
• Small shares do not deliver. Work needs a minimum concentration to finish. A line given a fifth of every team gets a little progress on everything and a release of nothing. This is the difference between allocation and consumption.
• Nobody releases an unused share. If line A's requests need 30% this quarter, a fixed 40% turns into work invented to fill it. Check the split against the sized requests every quarter and hand back what is not needed.

Where the headcount question does belong

Headcount is the answer to a different, slower question: quarter after quarter, which team is the one the plan breaks on? If platform has been the first line spent for three quarters and the requests turned away were ones the business wanted, that is the case for hiring there, and the record of parked and declined requests is the evidence. Hiring into a product line because it is the largest, while the shared team stays the constraint, adds people who will wait.

What to tell the line that lost

The product line whose request stopped at the platform line needs three things: that it was a capacity decision and not a judgement of the idea; which request was ranked above it and who made that call; and the date it will be looked at again. Without the second, the conversation moves to a side channel and the plan is renegotiated one favour at a time. The wording is in the scripts for declining a request.

If you use DeliverySheet

Each demand carries its estimate per team in FTE-months, with a confidence and the team's stance, entered in Plan and recorded at Commit. The Reports page adds up what is committed and still in flight for each team, with the number of demands behind each figure, so the team carrying the most is visible without a spreadsheet. The exits for a request past the line are the product's own: park with a review date, decline with a reason, or commit early with an exception that names who accepted the risk.

Two things it does not do, and you keep: it has no product-line field, so the queue for each line is a convention of yours (a word in the title, or the requester), and it does not rank across lines for you. The order is a decision, and it stays with a person.