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.