You Will Always Be on Unstable Ground

Markets shift daily; the demands of your industry are ever-changing, and your customer base is in constant flux with new additions and losses.

You are not standing on solid ground. Long-term planning is often a futile endeavor.

You Are Unaware of the Unknowns

Your lead engineer estimated that a certain feature would take about three weeks to complete.

You, as usual, doubled that estimate and added 20%, arriving at a timeline of seven weeks.

Yet here we are, twelve weeks in, and we aren’t even close to acceptance testing.

No, your developer didn’t fail. Neither did you.

Whenever you tackle a new project—common in software development—unexpected challenges will inevitably arise and disrupt your timelines.

This is simply a reality.

Honesty is Better Than Misleading Promises

Depending on your market's volatility and customer dynamics, you will develop an understanding of how far ahead you can plan with reliability. If you promise a feature beyond that timeframe, you are essentially misleading others and wishing for favorable outcomes.

In our case, our planning horizon is around three months. If a feature isn’t in that timeframe, I inform stakeholders: “I can’t say when we’ll work on that; it’s not in the next three months but remains on our backlog.”

Occasionally, I have to clarify why I can’t provide a timeline beyond three months, but most people understand and rarely push back.

Determine Your Planning Horizon

This will differ across organizations and even among teams. The goal is to establish how far ahead we can effectively plan without the ground shifting beneath us.

At my organization, that’s roughly three months or twelve weeks. In previous roles, it was sometimes only one or two weeks. This varies widely.

Identifying your planning horizon can be somewhat ambiguous, so don’t stress about perfect accuracy on your first attempt. Here are a few tips to help:

• If your planning horizon seems too lengthy, you may notice frequent adjustments to your backlog. Time to shorten it.
• If you rarely shift priorities, try extending your horizon by a few weeks and observe the outcome.

The objective is to maximize your planning horizon without introducing instability.

• A too-short horizon leads to excessive time spent planning future tasks, creating unnecessary meetings for both Product and Development teams.
• A too-long horizon results in constant re-prioritization of your backlog’s tail end, which also leads to excessive meeting overhead.

We aim for a balance that allows predictability while enabling our teams to maintain momentum without constant planning interruptions.

Organize Your Work into Categories

If this is your first time categorizing tasks, you’ll need to sort all existing work. After this initial phase, you’ll only need to categorize new items and move features between categories.

Your three categories are:

1. Now
2. Next
3. Someday

The Now and Next categories should contain sufficient work for your team to cover one planning horizon each.

Don't worry about ordering each task just yet. Populate the Now category with your most critical tasks—either urgent or important.

Then fill the Next category with the next most valuable tasks.

Everything else goes into the Someday category.

Focus Solely on the Now Category

Now that our tasks are sorted into three categories, we can concentrate exclusively on the Now category, prioritizing and assigning work to team members.

Various methodologies can be employed for this prioritization, such as RICE scoring or MOSCOW. Given that this work will be tackled within the next planning horizon, I typically don’t stress about achieving a perfect priority order.

It will all be completed in the next three months regardless.

Here’s an example of a priority matrix we created for our development team recently:

Some tasks are solo assignments for developers (blue), while others require support (red, orange, yellow). We also ensure to allocate some capacity for smaller quality-of-life tasks and tech debt (green).

Note that this matrix does not include specific dates; it simply represents the priority order for each team member within our upcoming three-month planning horizon.

This provides clarity for our teams while keeping administrative overhead low.

Transition Your Next Category to Now and Restart the Cycle

As our build cycle progresses, we continuously receive new ideas, both internally and externally, for future cycles. These are kept for our next prioritization round.

As we approach the end of a build cycle, product managers and development leaders collaborate to re-categorize our work based on the following guidelines:

• The Next category automatically becomes the new Now category.
• Any incomplete tasks from the current cycle that need to carry over are placed in the new Now category.
• Urgent items arising from market demands or customer requests can jump from the Someday or new idea categories into the new Now category.
• We still limit the Now category to a single planning horizon’s worth of work, meaning new additions typically require demoting existing tasks back to Next or Someday.

This concludes our planning cycle and illustrates how we prioritize our work! While it’s not a flawless system (and I’m not convinced a perfect system exists), it works reasonably well for our teams.

Communicate Extensively with Stakeholders

Transitioning to this model can be daunting for those accustomed to long-term roadmaps. Ensure you communicate thoroughly about the reasons behind this change and actively listen to their concerns to address their needs.

In my experience, over-communication is crucial during such transitions to maintain satisfaction.

Exercise Patience

It may take several iterations to establish an appropriate planning horizon.

Don’t be discouraged if you don’t achieve this right away; you’re still saving planning time by focusing on immediate needs. We still occasionally misjudge what fits into a planning horizon, even after using this system for a while.

Reassure Your Developers

If your developers are used to relying on a roadmap to determine their next tasks, they might feel uneasy about planning just a few weeks or months ahead.

Reassure them that this change isn’t due to a lack of upcoming work (job security) but rather the inherent difficulty of accurately forecasting far into the future.

That’s it! If you find this approach intriguing, give it a try, and best of luck!