Planning at two speeds

A roadmap I inherited had a beautiful quarterly plan and a sprint board that had nothing to do with it. The plan said three projects. The board said forty tickets, most of them urgent, none of them tagged to a project. Both documents were maintained carefully by people who believed in them. They had simply stopped talking to each other somewhere around week three.

Planning runs at two speeds, and the job is not to pick one. It is to make sure the fast one and the slow one agree about what is true.

The slow plan: a quarter, aligned upward

Long horizon planning is where the company's direction becomes the team's direction. The chain is usually simple to describe and hard to hold: the executive team sets a handful of priorities for the year, each function turns those into goals, and each team turns those into projects. My quarter plan has to be traceable up that chain. If I cannot point from a project to the company priority it serves, I either do not understand the priority or I should not be doing the project.

The trap is that upward alignment is only half the plan. The other half is what the team needs to keep working: the flaky pipeline, the service nobody wants to touch, the monitoring gap that turns small incidents into long nights. None of that appears in the executive priorities and all of it decides whether the executive priorities ship. So the quarter plan on my teams has two columns, business work and engineering health, and the second column is never empty.

The fast plan: the sprint, aligned to reality

Short horizon planning is where the projects become tasks and the tasks meet the calendar. Two weeks at a time, with a standup and a written update, is the shape most of my teams have settled on, though the rhythm has changed with the team and with how many partner teams we depended on.

The fast plan is where the truth shows up. A project that looked like six weeks in the quarter plan reveals itself in the second sprint as ten. A dependency that was a line item becomes a blocked ticket with a name on it. If the sprint board is not tagged back to the quarter plan, that truth never travels upward, which is exactly how I ended up with a plan and a board that had stopped speaking.

The fix is boring. Every ticket carries the project it belongs to. Every sprint review ends with one sentence per project: on track, at risk, or slipped, and why. That sentence is what the quarter plan is updated from.

Bandwidth is not headcount times days

The number I use for capacity has never once been the number the calendar suggests. Six engineers over a two week sprint is sixty working days on paper. Subtract the on call rotation, which takes one person out of project work entirely. Subtract planned leave, which someone always has. Subtract the interrupt work that arrives every sprint whether or not it is planned for, which on my teams runs at roughly a fifth of the time. Subtract a buffer for the things nobody predicted, because there are always things nobody predicted.

What is left is the honest number, and it is usually a bit more than half of the paper number. Planning to the paper number produces a team that is always behind and a manager who is always explaining. Planning to the honest number produces a team that sometimes finishes early, which people remember far longer than a plan that was ambitious and late.

Tech debt gets a standing line, not a plea

Every team has the conversation where an engineer asks when they will get time to fix the thing that slows everyone down, and the manager says after this project. There is always a next project.

I stopped treating debt as something that competes with features for the same slot and gave it its own. A fixed share of each sprint, around fifteen percent on most teams, goes to engineering health, and the team decides what fills it. On some teams the on call engineer owns that slot, which turns a week of interruptions into a week of fixing the causes of the interruptions. On others it is a rotating pick from a ranked list.

The share is not negotiable in a single sprint. It can be renegotiated in quarter planning, with a reason. That distinction is what keeps it from quietly becoming zero.

Estimate to seventy percent, on purpose

Estimation goes wrong in two directions. Teams spend days producing a number with false precision, or they refuse to give a number because the work is uncertain. Both waste the thing an estimate is for, which is a decision.

My rule is that an estimate should be right about seventy percent of the time, and it should take about an hour to produce. The method is to break the project into pieces small enough that someone on the team has done something similar, estimate the pieces, add them up, and add a range. Where a piece has no precedent, that piece gets flagged as the risk and we spike it first. The range is the honest part: this is six to nine weeks, and here is the piece that decides which end.

Then the estimate gets a cost. Engineer weeks times a loaded rate is a number the business can weigh against the value, and a project that cannot survive that comparison should not be on the roadmap.

Allocation is a conversation, not an assignment

Once the projects and the estimates exist, someone has to work on them. I have used three ways to decide who, and they work in this order of preference.

Ask. Most engineers have a project on the list they want, and a person who chose the work will finish it faster than a person who was handed it. Match to growth. If someone told me in a 1:1 what they want to be doing next year, the roadmap is where I find it for them. Assign, when the first two leave a gap, and say why.

What I no longer do is plan the quarter with two senior engineers in a room and announce it. The whole team plans. It takes an afternoon and it produces a plan the team believes, which is the only kind that survives contact with the sprint.

Watching the plan

A plan that is written and then filed is a wish with a header. Mine gets read every week. The sprint review updates the project lines. A monthly re rank asks whether the order still holds. And the quarter ends with a look at outcomes rather than output: did the thing we shipped move the number it was supposed to move?

The last question is the one most roadmaps are built to avoid, and it is the one that makes the next quarter's plan better than this one's.