LeadingIn Tech #6: Estimated Time of Arrival Panic

May 2021

Photo by Matthew Smith on Unsplash

Hi there!

This is the Issue #6 of the LeadingIn.Tech email. There are few things that scare me more than giving ETA's to stakeholders. I'm talking about "Estimated Time of Arrival" a term often used in software development to ask for the effort or the date for when a given task or project will be completed.

I must confess that whenever I get asked things like "Can you give me an ETA for when X will be done?" I enter in panic mode and all sorts of insecurities arise because deeply inside I know how complex the calculation of such response can get. On this edition I'll go through some common pitfalls that should be avoided to overcome the panic and give the best possible response you can give.

Source: https://xkcd.com/1658/

Never let your first answer be an actual date

STOP! It doesn't matter how you confident you feel, or how much experience you have. Never ever say the first date that comes to your mind. It will be wrong, period.

It is very likely that you don't have all the context of the ask and that there are a quite few dependencies you haven't even had time to think of.

Even if you will take the time revisit your answer before giving your final answer just avoid saying it just yet. Chances are that the offset can be big enough to hurt your credibility and raise a lot of questions on why is there such a difference from your original date. So do yourself a favour and hold it.

There are no extra points for optimism

Now, you might think that you or your team is experienced enough to be able to accurately estimate the efforts for the ask, and yes actually the effort might be somehow accurate. But efforts do not map directly to ETA's.

The universe is full of entropy and your project plan is not free of it either. Being too optimistic is the same as ignoring this which impacts your capacity to be accurate when giving your estimates. So make sure you add your Entropy value to whatever estimation you do. Just for fun let's use S as a wink to the Boltzmann's entropy formula

This entropy value will depend on the size or your organisation. I'll change depending on the complexity of the project or the dependencies across different teams or even multiple companies you need to complete the work. Larger organisations have more complex systems, dependencies get affected by other project plans, external companies will affect you with other environmental causes. As you can imagine any of these circumstances will make your entropy even larger.

You will need to find what is the best value of S for your project, team, organisation or company. A common known rule of thumb is that S = 1.3 which means that your ETA should be 30% further away than your best estimate. This number could go up or down depending on these many factors.

Now let's give a funny name to our equation for the final ETA you will be giving to your stakeholders, let's name it f(eta). Given that t is the time on when you plan to start, S your environmental entropy and eta your best guess estimation. The first equation will look like this.

Don't let your assumptions fool you

But this formula seems too simple for what happens in reality. When planning a task or a project, it's easy to rush on assumptions and create plans according to those. This is another factor that might delay your actual completion date if along the way you discover that they were wrong. I would encourage you to make those assumptions as explicit as possible and have them written down and discussed with your stakeholders. One way of doing that is by providing a comprehensive Frequently Asked Questions (FAQ) to the input specs. That will not only help you, but the stakeholders to understand what the final solution will consider and what not. If you managed to clear as many assumptions as possible you might still want to get the ratio of how many assumptions are you making compared to your actual requirements and specifications and add it to the equation, let's call this ratio A.

Divide and conquer

Now that you have a listed a detailed set of requirements, you are understanding better the problem and the work that needs to be done to complete the task. At this stage software development teams need to work on breaking the problem into the most atomic parts and start building a design that will satisfy all of the requirements. Each of this parts can be estimated individually and the aggregation of all will give you combined effort towards giving a completion date.

One of the advantages of dividing into smaller parts is that you can individually assign Entropy and Assumptions values to each part which will help you be more accurate in your individual estimations. This is also useful when splitting larger projects in a set of milestones that can be delivered individually.

For the sake of time and not to make this post too long I'll stop adding complexity to the equation by adding time allocation, parallelisation of tasks, dependency trees, or just simply team capacity to the mix. You can imagine now what I meant at the beginning of this text when I said that I used to enter in panic when being asked to give ETA's. Does this equation look similar to your current thought process?

Communicate your final ETA

It's now time to share your detailed plan and your f(eta)'s. This is your opportunity to show how and when are you planning to complete the ask and what specific problems will your deliverables solve. A detailed plan is helpful for driving conversations where what it seems to be a far away date its actually the result of a well thought process that produces better and more accurate estimations. When communicating ETA's you'll need to make sure that all the risks and their mitigation plans are included.

Is it a forecast or a commitment?

This is it, you have given a date. Now another tricky question comes to place "Is this a commitment?" The short answer is no, ETA's are not a deadlines until someone or something makes it so. Deadlines can take the form of marketing campaigns, public release dates or any other time sensitive factor that requires your partner teams to plan ahead and create ripple effects across the organisation if any of the dates are not met and potentially end up hurting your business or your customers.

Remember to be aware that by giving ETA's they'll be used as inputs for your stakeholders who will make plans based on them. This means that by giving accurate estimates and delivering accordingly you are helping reduce the overall entropy for your organisation and your team.

Wrapping up

Next time you need to provide an ETA remember this checklist for you to run when working on estimating ETA's before you give a response:

• What is the value of entropy you will use?

• Do you have a detailed list of requirements?

• How many assumptions are you making?

• Have you split the problem in its most atomic form?

• Have you estimated each part separately?

• Are you planning on having intermediate milestones?

• Communicate the plan together with risks and mitigation plans.

• Have everyone to align on wether the ETA represents a commitment or is for forecast purposes only

💬 Join the conversation

💡 New this month!

I'm excited to announce I've created a discord server and I'm inviting you to join me in the conversation. There you'll find regular updates on whats happening in LeadingIn.Tech and open the door for sharing discussions about leadership and technology.

Be the first to join! See you there... Join the LeadingIn.Tech Discord Server!

📄 Articles that inspired this post:

📄 Agile Estimation: Why The Fibonacci Sequence Works

📄 The Art of ETA. How to give precise development time… | by Dana Yudelevich | Level Up Coding

📄 Other articles added this month:

📄 Debugging engineering teams: Groundhog Day | LeadDev

📄 How to be Remote-First When You Still Have an Office

📄 How you're causing low employee morale at your company

📄 TBM 20/52: A Product Super-Skill (Balancing Divergence and Convergence) Ten things you need to know before making a build vs. buy decision

📄 The eight flavors of engineering management | LeadDev

🎬 Videos

🎬 Creating and sustaining motivation in engineering teams | LeadDev