You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 5 minutes
Technical estimation doesn’t have to be a grey area.
After you’ve done the technical planning for a large project, you will be faced with a question: How long will all of this take?
This is exactly the question I was asked by my product partner after I delivered a technical plan for a multi-year initiative we were collaborating on together. As many engineering leaders will know, this is far from an easy question to answer, especially on larger, more ambitious projects.
But with a mix of teamwork and organization, I was able to provide relatively accurate timelines to project stakeholders.
Generating a time-based roadmap
Despite all the technical research and planning I had done for the long-term project, I didn’t yet have a time-based roadmap to share.
There were a few different ways for me to generate one. First, I could carve out a few days to learn the domain and dig into the code; eventually, I would resurface with a rough estimate for how long the work would take. While this might have worked for planning one or two chunks of work, this was a much bigger initiative. How could I possibly estimate ten project subsets?
The second obvious option was to shoot from the hip. This would placate stakeholders by giving them a date they could focus on. But this approach had many downsides. I had seen this done before, and it always led to engineers being stressed out and overwhelmed while trying to deliver on a deadline that they had not been involved in committing to.
Neither of the two obvious approaches seemed ideal to me. I didn’t have the time to properly estimate multiple projects, but I also didn’t want to commit to arbitrary deadlines. So instead, I experimented with a third option: I involved my team in the technical estimation process.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Involving your team in project estimations
I had hatched a plan to get my team involved in estimating. Firstly, I divided the team into two groups so that the skill sets and expertise were fairly divided. I compiled the list of projects and divided them between the two groups, and assigned approximately half of the projects to each group. Finally, I created a definition of done for the estimation process: both groups were to produce a “level of effort” document for each project subset being estimated, as well as any possible solutions to achieve it (including tradeoffs for each solution).
Each group was responsible for estimating how many engineers could work on it in parallel, as well as the number of engineering days it would take to implement the work. I also asked each group to assign a T-shirt size to each project subset.
Each group had the freedom to decide how to self-organize in order to get the work done (although pairing and collaboration were highly recommended). I also encouraged each group to identify opportunities to cut scope from the projects they were estimating; if a product requirement could be achieved through a simpler technical implementation, or if a product requirement added many additional layers of complexity and development time, engineers were empowered to identify those requirements as opportunities to negotiate scope with our product counterparts.
At the end of the three days, we reconvened as a team to share our estimation documents with one another. There were a few benefits to this session; first, it allowed the team to get a sense of the size of each of the deliverables we needed to execute upon. Second, it allowed us to align on our T-shirt estimates as a team; since we had divided up into groups, it was important for us to be on the same page about what constituted a small project versus a medium-sized one. We had to be sure that one engineer’s definition of a large, multi-month project aligned with every other engineer’s definition of the same.
More like this
Putting the estimation into practice
At the conclusion of the estimation exercise, I solicited feedback from the team. The consensus was unanimous: every single engineer found that the timeboxed, collaborative estimation process was useful and provided clarity on the work ahead.
One of my reports noted that the process had allowed them to dig in and clarify product requirements while gaining a common understanding of the work and sizing of the projects. Another noted that finding ways to descope product requirements was really impactful – knowing what was essential and how to prioritize it gave them much more confidence about the work ahead. Every single engineer said they wanted to do this kind of exercise again for future projects.
Based on the feedback from my team, the biggest points of improvement were the bounds of the experiment itself. Some folks found that the number of projects we were estimating at once during that three-day period was too many, and they couldn’t do each project justice. Another noted that estimating based on the number of engineering days was more useful than loose terms like “small”, “medium”, or “large” that stem from Agile’s T-shirt sizing estimation methodology.
From estimates to timelines
After the experiment, I reviewed all the “level of effort” documents and compiled a list of the projects and the team’s estimates for them. Then, I added a reasonable buffer of about 30% additional time to each estimate. This buffer built in space that would account for company holidays, PTO, unexpected priority shifts, and undiscovered complexities. From there, I sequenced these projects into a Gantt chart based on our release milestones for the upcoming year and eventually developed the first draft of a time-based roadmap.
In the end, the deliverable I produced wasn’t a roadmap that I had cobbled together through random guesses or assumptions, nor was it a timeline that I had generated in a silo. The entire team contributed to building it through the collaborative process of researching problems, assessing complexity, and evaluating project requirements and scope together. Everyone had a hand in defining the timelines since we had generated our estimates as a group.
October 15 & 16, 2025
Agendas for New York events are live! 🙌
Final thoughts
Engineers enjoy being involved in evaluating, estimating, and scoping their work. While it might feel easier to try to tackle time estimation on your own as a manager, bringing your team along in the planning and estimation process is a great way to share context and clarity with the rest of your team in a relatively short timeframe. For large and long-running projects in particular, socializing the scope of work and empowering your team to contribute to setting the timelines will pay dividends in the long run.
