Software Estimation Tips For Effective Software Engineering Execution

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:

Estimations should have clear, date-based milestones that are used as critical project health checks

Setting clear milestones for smaller individual deliverables of a larger body of work is critical because it acts as a forcing function of:

• Accountability
• Accurate Scoping

Accountability

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:

• Reconsider any underlying assumptions and re-adjust timelines
• Hold yourself or others accountable to the expected output that was agreed upon
• Communicate any blockers or delays with stakeholders
• Communicate progress with other ICs working on the project

Accurate Scoping

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

Seek the unknown ASAP

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

• Known Knowns
• Known Unknowns
• Unknown Unknowns
• Unknown Knowns

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

Estimations precision should consider and be associated with confidence

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:

• I’m 90% confident this can be done in 2 months
• I’m 40% confident that this can be done in 4 weeks

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?

Estimates should become more precise and accurate as the length of the project goes on

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.

Estimates should be updated and communicated as soon as new, impactful information is discovered

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.

Estimates should not be padded too highly (conservative) nor too tightly (optimistic)

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:

• Losing credibility as someone who is padding too much to avoid maximizing their output
• Reducing impact as less work gets done
• Losing out on potential projects you’ve pitched because you propose them as higher cost than they actually are

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.