Keep your promises first
The aim of long-term planning is to make promises. "We'll have feature A ready by November."
The more promises we make, the more brittle our plan becomes. Minor setbacks can break our tight schedule.
Let's take a look at this long-term plan.
We've promised a stakeholder that we'll have the integration with Sharepoint ready by week 10. Based on estimates, we've given ourselves three weeks to build it. The 🔒 icon indicates our promise. If we were to push this feature back to week 12, we would be breaking our promise. That's why we consider this date locked. It's a hard deadline.
But the estimate of three weeks is dodgy. Since estimates rot and our developers don't have experience with Sharepoint, we fear it might take more than three weeks. Half a Sharepoint Integration isn't very valuable to the users, so we don't have much room to play with the scope either.
The classic approach is to sacrifice the buffers and plan more time for the Sharepoint integration:
This way, we have six weeks to spend. That should be plenty, right? The problem with this approach is that our long-term plan is now a "tight plan." There is no more buffer. Tight plans always fail. If Improved Search starts slipping, it's a cascading effect. If we get new insights during week 2, we cannot adapt. A single issue in production can derail our entire plan.
The best solution is the one that gives us maximal flexibility:
By keeping our promises first, we free up the rest of the long-term plan without losing our buffers. We've optimized our plan for flexibility. We are always in a position to change without breaking a promise.
There are exceptions to this rule. Maybe we must wait for the Sharepoint team to configure their server in week 8. That's a hard dependency. In that case, we should start renegotiating our promise with the stakeholders today. But more likely than not, we are making our life more difficult by building just in time.
It might sound like a straightforward approach, but it's relatively uncommon. We've built a culture of prioritizing backlog items based on "business value." The things our customers really want, we'll create first. That way, we optimize the backlog for value. But I feel optimizing for flexibility is often the better way to go.
Our promises beat business value when it comes to priorities. Or better: doing what we say we would do is business value.
Organizing your backlog to maximize flexibility is the best way to do practical long-term planning.