Anytime a new project is spun up the first thing that is done is normally to ask how long will this take. Some folks are explicit on this ask and some ask other questions to tease it out but everyone wants to know how long a project will take. Some engineers are better at this than others when put on the spot to give an ETA and some just say they will get back to you. Here are some tips for proper expectation setting when working on a project.

Think Through Admin tasks

This one is normally the hardest. Every engineer can think through the coding tasks that need to be done to ship a feature but rarely do we take into consideration the admin tasks to make that happen.

Please do not however during your agile ceremonies bring up everyone of these details when breaking down stories or grooming the backlog. This is something to keep in mind when providing estimates but no need to go into the messy details unless asked to explain. Try to keep the explanation clear and concise.

Documentation

A big one forgotten is documentation. Not allotting time to update README, wikis, and runbooks can easily make the simplest task get horrible off schedule. Engineers really underestimate the time to build out a good README.

Git Management

Another one forgotten is time spent managing git. This one seems small but have you ever accounted for the time for code reads or conflict resolution, or just discovering which repos need to be updated and attaining access to those repos? Folks who you need code reads from may not be working on the same feature you are working on and will be distracted with their own tasks. Everyone could be working in a monorepo where one engineer decides to “refactor” a large chunk of code which steps on everyone touching the same code base. Git is sometimes a massive time sink.

Write it all down

If you are like me your memory is terrible. I cannot remember anything I did yesterday unless it is recorded in some way. Lately, I use a simple markdown file in git with the tasks I have completed(and when) as well as the tasks I still need to complete. Roughly ordered by priority. I write everything down for a project just so I can remember all the admin gotchas above.

Just by writing things down you start to think more structured. Meaning, when someone asks you “how long will this take” you can quickly recall a similar feature and all the tasks it took to get done down to whatever detail you want. This can go a long way at estimating an ETA.

Communicate early and communicate often

I usually tell junior engineers I work with on projects that I do not care how long a task takes as long as I know you are not blocked. If you are blocked or think you are blocked come find me and let me know immediately. We will help get you unblocked ASAP. It is always best to communicate status of a project to stakeholders. I do not mean letting them know every little commit on every little ticket but let them know when the feature hits Pre-prod, when it has passed / failed QA testing, or especially when it is blocked. Stakeholders always want to know when things are blocked and when hey become unblocked so they can determine for themselves if they should step in and help prioritize the work to unblock or just to know the impact of the timeline.

Wrap up

This is not an exhaustive list. There are many other tricks out there or frameworks that help you break down problems better. These are just things I constantly have to remind myself and have built a personal process around to make sure these things are always at the top of my head when working through projects.