“Anti-Patterns” in Software Estimation: Survival Guide Vol. 5
Avoiding common mistakes and pitfalls in estimating projects.
The number one question in all of software engineering is and has always been…
When is it going to be done?
In fact, I can’t think of a more divisive topic in the field than this one. The concept itself is both the subject of intense study and endless ridicule. There are as many books on the topic as there are memes. For better or worse, dealing with estimating projects is a core part of the developer experience.
Interestingly, what I find in practice is that many teams spend too much time debating the systems themselves instead of focusing on optimizing the approach they have chosen.
My personal philosophy is that ANY system can work for you as long as it is well implemented and fits your team and product. Where things tend to go wrong is in how you execute the system not the system you chose.
With that in mind this article will take a look at some of the most common patterns in which estimating can go astray.
(NOTE: Although we are not covering specific estimation processes in this article, I’ve included some starter resource links below.)
📉 Estimating “Anti-Patterns”
Producing project estimates is tantamount to predicting the future. A hard task for any of us honestly. Implementing the correct approach for the product and the team is critical in reducing risk and producing predictable estimates.
But even the best systems and the best intentions can have weaknesses and blind spots.
Here are four of the biggest pitfalls and bad habits that can create risk and derail your estimation process.
#1) Thinking that Scope == Schedule
This is always the hardest paradigm shift to make when you get into estimating.
The scope of the project IS NOT the same as the schedule.
Scope is the amount of work required to build the thing. (Ideal)
Schedule is the calendar time required to do the work. (Reality)
Seems simple enough but in practice teams get tripped up in two ways:
Scope is often measured in time, which makes it feel like a schedule when it is not
Schedules fail to account for the realities of life that are not captured in the scope. ie. Meetings, Trainings, Days Off, Scope Creep, etc.
That is why this is such an easy mistake to make. With Scope that feels like a schedule and a schedule that only accounts for the specific Scope of an effort, the two will naturally blend together and produce a poor estimate.
Quick-Note: This is why Scrum is so popular. It creates distinct lines between Scope (units of work) and Schedules (sprints) and aides in decoupling scope from time with the use of story points.
#2) Treating all Estimates as Equal (or extremes)
An all too common practice in a lot of organizations is to develop an overarching bias towards your estimating process. Although this can certainly happen at the individual level, it often manifests itself as how the company views the dev team as a whole.
Depending on historical performance, the view will form that the dev team is either overestimating (Sandbagging) or underestimating (Too Optimistic).
Once this impression is set the downward spiral can be severe. The more the business attempts to ‘adjust’ for the perceived extreme of the estimate the more the team will lean into that extreme. This will continue to degrade until all trust between the business and the dev team is gone. An unfortunate but not uncommon occurrence.
The way to stop that cycle is with transparency. As much as we don’t want it to be, bias is a real factor in any estimating process because in the end it is a people process. But it is not all or not like the scale above. It is a spectrum on which each person sits based on their experience and tolerance for risk.
They key is to understand your own bias individually and as a team. Be transparent about it and work with it.
Quick-Note: This is why velocity is such an important metric in development. It both acknowledges and accounts for estimate bias.
#3) Properly Defining “Done”
What is “done” really? Potentially a philosophical question, but one every dev team needs to know intrinsically for themselves and their process.
When left undefined, “Done” is left up to the perception of the individual. Be it leadership, sales, ops or the devs themselves.
This is where dev teams can get into serious trouble. I see it most often in early stage companies or dev teams with weak or simplistic process.
It is all too common a trap for devs to communicate to stakeholders that they will be ‘done’ at a given time and date and completely forget things like peer review, QA and deployment. Even more so for other process steps like Training, Support and Marketing.
This is where a well defined SDLC makes or breaks you. There should be no ambiguity here. Your process should capture and define all steps required for your product and org and everyone from sales to engineering should know it inside and out.
Quick-Note: Communication is paramount in avoiding this mistake. The ENITRE org should be aware of and understand at a high-level what the SDLC looks like.
#4) Succumbing to “Rolling Failures”
This is likely the biggest self-inflicted pain I see engineering teams subject themselves to when it comes to project estimations.
The scenario is simple and I’m willing to bet you’ve experienced it many times. The team has produced an estimate and the due date has come and we are not done. There is frustration, disappointment, potentially finger pointing and blame. When the dust settles the obvious question has been asked again: When will it be done NOW??
Unfortunately the natural instinct is to scramble, try to fight the disappointment and offer up a new deadline that is likely far too aggressive. Forcing another probably miss scenario and likely an even MORE aggressive next target. I call this cascading effect “rolling failures”.
To avoid getting trapped in this cycle you need to build resiliency in the team so as not to fall victim to the emotional pressure of the initial failure or the sense of immediacy that it will certainly create.
Now is the time to pause, reflect, and determine the best course of action. I always tell my teams when things go wrong and we are communicating failure “now is the time to rip the band-aide, let’s make it count” By this I mean that if we are going to communicate bad news (ie. The missed deadline) now is the perfect time to set realistic and potentially further disappointing news.
Although difficult, it is far superior to face things head on then trying to smooth a missed deadline over with a completely unrealistic recovery plan.
Quick-Note: Implement a process of Root Cause Analysis into your SDLC. Forcing a hard stop and retrospective into your process will provide the necessary time to understand and regroup properly.
<read more on root cause analysis>
🤔 A Change in Mindset
As engineers we become overly preoccupied by correctness. Always searching for the perfect system to produce the perfect results.
This leads to teams constantly debating, over analyzing, and endlessly tweaking or changing their approach to estimating.
In reality this has the exact opposite effect then intended. The resulting process becomes muddied, too complex or misaligned to the current state of the team and product.
Instead of constantly looking for the ‘best new approach’ we should spend more time focusing on what isn’t working and optimizing. Putting our focus on bad habits and subpar performance in our current system before considering a move to a new one.
Continually evaluating your process and addressing common issues like those above will go a long way in creating consistency and predicability in your future estimates.
📣 As A Leader
The biggest impact you can have as a leader is to constantly police the process. Guiding the team around and through obstacles is central to your role.
Learn the early warning signs of when things start going sideways for your team and be proactive. This is where coaching can have outsized impact. Use missteps as a teaching tool and continually educate on your estimation process to avoid future setbacks.
🤐 Unpopular Opinion
There is no perfect estimating system. There is only the right one for your team/product/organization/etc.
All of the teams focus should be on executing whatever system you have adopted to the best of their ability. So much of the ambiguity in producing good estimates comes from a lack of understanding in the process or communication to stakeholders.
Running a clean process is far greater than having the “right process”.
📚 Deeper Dive: Recommended Reading
Although we’ve sidestepped it in this article, having a solid estimation system is critical to a functioning SDLC. Here are some additional resources worth checking out on the topic.
COCOMO II (interesting read)
🚀 Take Action Today
Get grounded and comfortable with your process.
If you don’t know your process, go ask.
Don’t have a process? Start by creating a simple one, documenting it and communicating it to the team.
Nobody is following the process? Start calling it out and drive alignment.
The foundation of producing good estimates is consistency. You have to have a repeatable approach to have consistency. It all starts with a well defined and communicated approach.
🎙Empathy Scrum Update
Accountability is everything and the heart of a good scrum update is about peer accountability and information sharing across the team. This section is about sharing what I’m working on in the hopes that others can relate.
What I’ve done:
Worked hard to address ‘Rolling Failures’ in our process. This can often stem from strains in the organizational culture and can be challenging to unwind.
What I’m doing:
Focusing on coaching the team around these common roadblocks to good estimates. Working on removing ambiguity from our processes.
Blockers:
Unlearning bias in the team around bad practices. Avoiding the pitfalls above are far easier said than done in reality. It’s critical to constantly evaluate and reinforce processes week-over-week to make progress.
What is the Motley Bool Survival Guide?
Well, I’m glad you asked. 😁
The “Survival Guide” is my humble attempt to tackle topics in product and engineering through a lens of shared experience and a smidge of humor.
Subscribe below to follow the journey and receive new volumes bi-weekly!