December 16, 2022
Estimating Software timelines is one of the trickiest parts of being a software engineer, and a constant source of tension between engineering and non-engineering stakeholders.
Despite the term “engineering” being used synonymously in software development, software development is very different than other types of “engineering”, which can at times be very precise, scientific, mechanical, and mathematical.
Software is moreso compared to an organic organism which is constantly changing and growing, whose complexity and development can be mysterious and hard to understand at times.
In other words, developing software is not always so clear-cut, which can make estimations really tricky.
Here are some tips I have to help any software engineers providing estimates, in order of importance, which I’ll explain in more detail below:
Setting clear milestones for smaller individual deliverables of a larger body of work is critical because it acts as a forcing function of:
By setting milestones and sub-goals, you are essentially holding yourself accountable to make the expected progress for the project, thus maximizing its chance for success and hitting the target estimate. If a milestone is missed, it is a clear alert that something is off- whether the scoping was off, or the effort wasn’t put in, etc.
Therefore it acts as a critical signal and opportunity to:
By thinking of milestones up front, it acts as a natural forcing function to think through the smaller individual pieces of work, and how the work will be sequenced. It naturally encourages one to think about their approach and gauge whether their estimates are effective. It also acts as an opportunity to think of whether the approach they are taking is easily communicable to outside stakeholders
Earlier in the post I mentioned how software is often referred to as an organic system with lots of complexities and mysteries to be discovered
Therefore, a fair assumption to make for most projects is that there are a set of
If we always knew every detail of the system we are building on and are building things within that context we’ve already built before, estimation is very easy. Everything is already known, and all work is predictable because you’ve already done it before in that specific context. That’s why we should focus on the unknowns
The riskiest parts of software development are the unknown unknowns- those are the big surprises that cause huge headache that delay projects on end. Ideally these can be identified in the estimation phase, but in my opinion, the nature of these unknowns is often times only discovered once development is well underway. That is why Proof of Concepts and drilling from both sides of the tunnel are such helpful tactics for de-risking projects.
Next is the known unknowns- these are things you know are going to be tricky are hard to tackle but are still unsure what it will take to get it done. Identifying this upfront is crucial, because then you can do some scoping work and reach out to any subject matter experts as needed earlier on in the scoping phase
Earlier in the post I mentioned how software is often referred to as an organic system with lots of complexities and mysteries to be discovered. Additionally I’ve highlighted the impact of unknowns in software development
The earlier in the project lifecycle you are, where there has been less development, less discovery, less momentum, the less likely your original estimate is accurate.
Therefore, estimates should be looser and assumed to be less accurate earlier on in the project lifecycle, and then tightened
Giving a confidence interval and a range can be very helpful:
By doing this, you are sharing the true nature of what software estimates look like, and are setting realistic expectations. It also acts as a natural forcing function for yourself to really gut check your estimates. What does 100% confidence look like? What does minimal confidence look like? When you give estimates, how confident are you truly in the number you’re giving out to stakeholders?
Going back to an earlier point around unknowns, a reasonable expectation to have is that as a project is underway, and as more details are discovered, and as the team’s output cadence is clearer, the estimates and timelines can be more confident than earlier in the project when there was less information available.
Communicate early and communicate often. I’ve literally never seen anyone get penalized for too much communication and project updates to stakeholders. Use the milestones as checkpoints to communicate progress and risks, but better yet, if new information is discovered that might have an impact on the milestone, communicate it ASAP so everyone is in the loop.
If you are overly optimistic with your estimates, you will suffer, your project is put at risk, stakeholders will be disappointed, etc.
If you are too conservative, you risk the following:
In other words, you want people to trust your estimates, and you want to be able to provide accurate estimates when possible as always taking a conservative approach can lead to less opportunities for impact
I'm Patrick El-Hage and I live and work in San Francisco. I'm also on Twitter.