The product manager perks up during the meeting with an urgent statement: The business wants to deliver this new feature and needs to know how long it will take us to build it.
It’s a familiar situation for engineers. What follows is the dreaded estimation process, also known as sizing.
Our previous approach was to split the proposed work into smaller high-level tasks that will be required to build it out. Then we would estimate how much effort each task will require in order to get an idea of the total estimate for the whole project. This is where estimation becomes challenging, as multiple factors come into play.
Three Key Elements of Estimation
Every technical project estimate must account for three key elements:
1. The knowns
These are the parts of the implementation that we are familiar with. We’ve done them before and know exactly how much effort it requires.
2. The known unknowns
These are the complexities and blockers we can foresee. We have ideas on how to solve them but are unsure how much effort they will take because we haven’t done them before.
3. The unknown unknowns
These are the surprises—the blockers and complexities we didn’t see coming. The invisible walls we only realize exist after we run straight into them.
The problem with static estimates
Our previous approach to estimating was to size up the effort based on the knowns and our anticipation of the known unknowns and leave a little buffer for surprises. The number of weeks we came up with often seemed reasonable at the time but was almost always too optimistic due to a variety of reasons such as:
- Failing to account for team capacity changes (time-offs, holidays)
- Overlooking other ongoing projects
- Requirement changes midway into the project
- Inability to account for unknown unknowns
These issues led to frustrations during the implementation phase and poor coordination with our stakeholders. So we decided to try a different approach to estimation. We shifted to using technical implementation roadmaps (TIR).
How we create a technical implementation roadmap
Like a typical roadmap, it has
- A vertical axis representing the phases of work (technical tasks)
- A horizontal axis representing time
Above is an example for a project we split into 2 main workstreams. Each work streams has a few high-level tasks spanning an estimated 9 weeks. This setup was created in Figma, but we’ve also used Notion. Other visual mapping tools can work just as well.
Key elements of the roadmap
Workstream
The project is divided into different phases containing related tasks. The roadmap helps visualize which tasks can run in parallel based on team capacity. In our example, the project has two workstreams.
Implementation task
These are the high-level tasks required to build the feature. We try to avoid getting into the nitty-gritty details of implementation here.
Team members icons
Icons represents the team members. They are useful for visualizing capacity while estimating how long tasks will take and what can run in parallel.
QA task
We found it useful to block out time for end-to-end QA of the workstream. As we find, it often takes a non-trivial amount of time to test then resolve any bugs or unexpected behavior
Release task
For projects involving fresh infrastructure deployments, including a release phase can be useful.
Team member time-off blocker
Planned time off impacts team capacity and should be explicitly noted.
Red flags
Tasks containing unknowns are highlighted as risks to communicate potential timeline disruptions.
Using the technical implementation roadmap as a communication tool
The main goal of the technical roadmap is to enhance collaboration with stakeholders. We’ve found it useful in several ways:
Communicating options
At the start of a project, stakeholders often push for an optimistic deadline while desiring an extensive feature set. Instead of pushing back on every extra requirement, we draw out multiple roadmap scenarios showing different implementation options and their respective timelines.
For example, when a stakeholder sees a clear visual of how an extra feature would extend the deadline by four weeks, they can more easily decide on trade-offs.
Visualizing tradeoffs
Stakeholders often assume that a fixed team can deliver a high-quality feature within a short timeframe. This rarely works, and by the time adjustments are considered, it’s often too late.
The roadmap helps surface this issue early. It allows us to decide upfront whether to:
- Extend the delivery timeline
- Increase team capacity
- Reduce scope
Call out unknowns
Pointing out elements of the implementation as unknowns helps us communicate risk to our stakeholders. A roadmap filled with red flags signals that estimates are likely to shift due to unforeseen complexities.
Calling out risks early helps manage expectations and plan workarounds when roadblocks arise.
Adjusting the TIR during the implementation phase
Once validated with stakeholders, the roadmap becomes a useful tracking tool. Comparing actual progress against estimates allows us to quickly identify if we are falling behind—or even ahead—of schedule.
This provides the earliest opportunity to reconsider capacity, scope, or timeline and adjust accordingly.
Conclusion
Using a roadmap requires more upfront effort than static estimates, but the benefits outweigh the extra work. The visual timeline improves communication, planning, and decision-making across multiple stakeholders. It helps align implementation expectations early and allows for swift adjustments as the project progresses.