What is ETA on completion?

How to give precise development time estimations for your feature

Making promises you can’t keep

Imagine the following scenario: Greg is a Front-end developer at a startup. He’s been given a new feature to work on. His manager, Anne, is asking him for a time estimation. Greg looks over the design and ballparks “5 days”. Anne thanks him and goes on to report it to her manager.

Greg, much like most of us, did what he always does — tried to estimate the overall time it would take him, and give a very general estimation.
The issue? this feature will actually take Greg 14 days. It will need to be tested by QA, reviewed by the Designer and Product manager, and gradually released to test groups until its release is complete.

The result? Greg started working on the feature but kept postponing the due date because of issues he “couldn’t predict”. He had to work weekends to make time and his manager, Anne, was frustrated with the delay.

How could this have been avoided? simple — Greg should have done a proper technical design process before giving his ETA, communicating it better to Anne.

What is “ETA”?

ETA stands for Estimated Time of Arrival. In the development world, it often refers to an estimated due date of a project. When asked to give an ETA you are asked to estimate the effort of a task and the subsequent time it will take you to accomplish it.

How does an ETA differ from a Deadline?

In tech-speak, a Deadline is a non-negotiable date up until which the project needs to be done. There is little room for negotiating deadlines — most of the time they are set by external factors like public release dates, Campaigns, Competition, Board, and various other factors.

An ETA is much more flexible and depends on your internal estimation of the feature. As the name suggests, it is an estimation — it can vary and can end up being a bit shorter or longer. That does not mean that giving an accurate estimation is not important; ETAs are relied on for sprint planning and other departments' road maps.

Why should I give precise estimations?

When you give estimations and follow through with them consistently you are perceived as more accountable, reliable, professional & technically apt. Your managers rely on your estimations — and standing by them means standing by your word.

It builds better products

The process through which you reach an estimation will lead to a better-built product since you take the time to plan it based on code architecture and not make rash decisions due to time restraints or after-thought patchwork.

Getting to a good time estimation

The key to giving a good estimation is making the core decisions before development starts, making sure to answer any open questions.

1. Spec

Every feature should start with a proper spec. A spec is a written document, usually created by a Product Manager, that describes the feature in detail. It will usually explain the motivation for the feature and metrics it is predicted to effect. It serves as one source of truth for feature requirements and would describe the user flow and expected behavior of the UI.

Starting the technical design process without a Spec is a recipe for trouble since you will be working off of your understanding of the design or off-hand statements- which may not match the Product Manager’s vision.

2. Kick-off

A kick-off is a meeting in which the feature is presented to all those who will participate in the development process. It sometimes precedes the Spec which may be created following the kick-off. The goal of the meeting is to present the feature and explain the motivation for it; which pains is it going to solve? which users is it targeting?

During the meeting, an initial design or wireframe is usually presented, and the general flow is described. All stakeholders should be present in this meeting — the product manager, designer, developers (Front end & Back end), QA person, BI person, and whoever else is involved. It is a chance for all of those to understand the feature, ask questions, and raise potential issues.

3. Technical Design

This is where the magic happens. Technical Design is a process made by the developer working on the feature. It will eventually produce a document which details the development changes that need to be made.
This is your time to plan out the architecture of your code, plan out the logic, and make sure you understand what you’re going to build and how.

In the Technical Design document, I recommend writing down the following things which should help you come up with a development plan:

Feature description
Describe the feature to make sure you understand the main goals and the impact it would make. Note who will be your collaborators on the feature — who will do the Front end, Backend, QA, or PR reviews.

Target users
Different features target different user segments, such as first-time users, logged in/out users, etc. Make sure you understand which users this feature is for as it will probably affect development.

3rd party tools
Understand if you can and want to use any external tools or packages for certain parts of the feature. Compare the various options and choose which one fits your needs the best.

Current code structure
This is relevant if you are refactoring an existing feature or adding onto an existing one. It’s important to understand the current code and preferably speak to the original code owner to understand it better.

API contract
Decide on the API for the Backend/Front end communication; Which routes will you need to create or fetch data from, and how will the response object look like.

Development changes (Yes, this is the hard part)
Plan out your architecture- the components that should be added, object types, classes, DB changes, files that would be added. Describe the main changes in the code that this feature will require.

Mobile / BI / Testing
Be aware of any changes needed for Mobile-web, or how it relates to the mobile-app (if exists). Understand which events would need to be tracked for analytics purposes, and which unit/E2E tests need to be added.

Task breakdown
Extract the development changes into an ordered list of tasks. Think of the steps you need to take in order for the feature to be complete and the logical order you would do them in. This breakdown can be later translated into tasks on your Task management platform (like Jira or Asana).

4. Design Review

The Design Review is where your teammates review the technical design that you made. It can be a meeting where you present the design review document to a few other developers, to allow them to give feedback. If making a presentation sounds like overkill, sharing the document for comments will also do. It is sometimes the last chance to make sure you didn’t miss anything and get another pair of eyes on it!

Estimating effort

After you got your Technical Design reviewed and you have the final version, you can start evaluating the overall effort. You should start with the task breakdown- break each task into smaller sub-tasks and evaluate the time it will take you to finish them. Small sub-tasks are much easier to estimate than larger tasks.

When you have the list of tasks & subtasks with effort estimation you can sum them up- This is your initial estimation.

Consider the average time it takes to get your PRs reviewed. Make sure you add that time to the estimate, along with time for QA rounds, review with the Designer and Product manager, or other processes in your team’s workflow. I would also recommend adding more time if you are delving into an unfamiliar codebase or using a new tool for the first time.

Giving a final estimation

Now it’s time to take your estimation (let’s say it’s 14 days) and spread it out on the calendar. Count only the business days (no weekends), and take into account short days, holidays, or meeting-packed days where you won’t get much done. There you have it — your final ETA!

Communicating the ETA

When communicating the ETA to your manager or colleagues — use dates and not days. When speaking with dates it is much more clear when everything will be done. I also recommend explaining the release process and if your final ETA is the public release date or an initial release.

The push-back

More often than not, you will receive push-backs and raised eyebrows for your comprehensive estimation. This is the case when you give a thought out estimation based on technical design and include testing, PR time, and reviews — it gets longer and more realistic.

I believe it is better to give a real, planned-out estimation that may be a few days longer, than a general — mostly mistaken— short estimation, that would eventually bloat and grow.

When facing push backs, refer people to the technical design. Explain the process that you have made and what is included in the feature. Ideally, involve your manager in the Design Review so they can see exactly what comprises the effort.

Good luck and enjoy the process!

Note: This is a summary of a Talk that I gave for the Israeli Women-in-Tech group “Baot”.