One of the most consistent and complex challenges I navigate as an Engineering Manager is roadmap predictability.
There is an endless array of frameworks for estimating work and plotting roadmaps, yet the reality of software development is always tangled in variables. Stakeholders naturally want concrete timelines and absolute certainty. Engineering teams, however, know that software creation is an inherently fluid process of discovery. Over the years, through various projects and shifting methodologies, my approach to bridging this gap has had to constantly evolve.
From Continuous Flow to Concrete Milestones
Looking back at a previous role, my team utilized a Kanban-style approach. We operated with a continuous flow of a prioritized backlog and kept sprint planning incredibly lightweight. Because our goals were tied to quarterly OKRs, which were focused on maintaining a live product and incrementally adding features, there were no rigid milestones. We operated with broad initiatives, and for that specific environment, it worked beautifully.
Things grew tricky when we were tasked with building an entirely new mobile app within a strict deadline. The open-ended Kanban flow was no longer sufficient. The business needed concrete milestones and a predictable roadmap.
To solve this, we pivoted to ScrumBan. We blended the structured, time-boxed ceremonies of Scrum with the continuous, pull-based flow of Kanban. To build a reliable roadmap in this new model, we had to shift our mindset from measuring subjective “sprint velocity” to tracking objective flow metrics. We established a few ground rules:
- Fixed Story Sizes: We capped user stories at a maximum of five days of effort. This normalization is crucial because flow metrics rely on items being roughly similar in size to be statistically reliable.
- Work-In-Progress (WIP) Limits: By strictly limiting how many items could be active at once, we reduced context switching and stabilized our delivery rate.
- Tracking Throughput and Cycle Time: Instead of velocity, we measured Throughput, which is the total number of user stories completed per week or sprint. We also tracked Cycle Time, which measures exactly how long a story takes from the moment work begins until it crosses the finish line.
- T-Shirt Sizing Epics: We assigned T-shirt sizes to upcoming epics, giving us a rough conversion rate into a forecasted number of our fixed-size user stories.
To generate the roadmap, we stopped relying on arbitrary sprint commitments and turned to our historical data. By mapping the T-shirt sized epics into a forecasted number of user stories, we could divide that total by our average Throughput to project an end date. Meanwhile, our average Cycle Time gave us statistical confidence intervals for individual deliverables along the way.
It is important to note that building a predictable roadmap using these metrics was relatively straightforward for this specific project. Because we had extensive experience building similar mobile apps before, the technical path was well-understood and highly predictable.
The Optimistic vs. Pessimistic Dilemma
My environment changed significantly when I took on a new project focused on building an automated data ingestion pipeline for thousands of records, powered by artificial intelligence and advanced image processing. This was a highly complex, distributed system spanning multiple subsystems.
The inherent predictability I had relied on previously vanished entirely. Estimating work in an uncharted AI landscape is vastly more difficult than estimating a familiar mobile app build. Because historical flow metrics are ineffective when a team is tackling unprecedented technical challenges, my approach had to evolve again.
To account for these immense variables, I began providing stakeholders with an estimation range for epics: an optimistic forecast and a pessimistic one.
The logic seemed sound, but it quickly created a new kind of friction. The business stakeholders still ultimately wanted an exact date. They highly doubted the optimistic estimates, knowing from experience that best-case scenarios are rarely realistic. Conversely, they were entirely unsatisfied with the pessimistic estimates, pushing back against the built-in buffers for unknowns, unplanned distractions, and holidays that inherently dilute a timeline.
Even taking an average of the two extremes did not solve the problem, because it still was not a guarantee.
This tension peaked during a recent planning meeting. I presented a timeline based roughly on a buffered, middle-ground estimate, explicitly noting that the end date was still subject to change due to unplanned priorities or technical discoveries. While one stakeholder was comfortable with this, a senior leader objected entirely.
Their response was blunt: “Don’t give me a timeline if you aren’t sure about it.”
It was a pivotal moment of frustration. How do you give a hard, inflexible date in an inherently uncertain, evolving environment?
Waterfall Minds in an Iterative World
The root of this friction is a fundamental mismatch in philosophy. Business stakeholders often attempt to apply a Waterfall mindset to an Agile reality.
In a Waterfall world, everything is perfectly planned and clear upfront. But this expectation completely ignores the reality of how software is built. As David Farley articulates perfectly in Modern Software Engineering:
“Defining the process end to end in some kind of plan requires us to have covered everything that will happen. This is an inherently limited approach to solving problems. We can only solve the problems that we can understand up front.”
Organizations that cling to waterfall-style planning expect to perfectly estimate costs and execute plans without a single deviation. The reality of software development simply does not work like that. Farley points out a harder truth about our ability to predict outcomes in this industry:
“Industry data says that for the best software companies in the world, two-thirds of their ideas produce zero or negative value. We are terrible at guessing what our users want.”
Because we cannot predict the future or anticipate every technical hurdle, the only effective approach is an iterative one. Software engineering is an open-ended process where we continuously refine our understanding and our product as we go.
The Breakthrough: Horizon Planning
Following that tense stakeholder meeting, I sat down with my manager to untangle the confusion of what we should actually be sharing. We realized we needed to stop trying to predict the unpredictable.
The solution we landed on is a pragmatic middle ground called Horizon Planning:
- The Near-Term (Next 1 to 3 Months): We plan the most predictable, well-understood epics. Because the scope and technical challenges are clear, we confidently provide reliable estimates and timelines based on our capacity.
- The Far-Term (Next Quarter and Beyond): Work is placed roughly into quarterly buckets. For these epics, we explicitly highlight the unknowns that we still need to figure out. We communicate themes and directions, but we strictly avoid assigning clear timelines or hard completion dates.
By clearly delineating what is known from what is unknown, we give stakeholders the short-term certainty they crave, while protecting the engineering team from being held to impossible standards on ambiguous, long-term work.
True agility is not about refusing to plan. It is about having the honesty to admit what we do not know yet, and the flexibility to adapt when we finally figure it out.
Leave a Reply