Checklist to estimate time to make a thing

Writing this (mainly for myself) because we keep getting bit in the butt with our estimations.

This checklist helps interrogate our assumptions. On first glance a task may seem easy but it could hide a ton of other tasks.

Generally I find quintupling our first estimate brings us a lot closer to the truth.

Data

Where does it come from?

• Is it easy to access?
• Do we need authentication?

Does it contain all the properties we need?

Have we actually seen it or are we just assuming that we probably have this data because it's so obvious? (Don't assume. lol. 😭)

Does it need to be transformed?

• Is it complex to transform?
• Does the data's reliability depend on many third parties? E.g., country calling codes 📞 could start with +, 0, 00, or a whole slew of other patterns depending on country. It might take a lot of investigation just to figure out what the data is really about, and how to break it up into component parts suitable for our use case.
• Does the new form need to be stored somewhere?
• Should we work it into a regular ETL and CD process? E.g., daily cron job to ETL public transport traffic data, transform it, test it, then deploy to a server that uses Docker in Kubernetes in Azure 😅.

Do we need to communicate with several parties over a period of time to get this data, and in a form we can use?

UI/UX (if front end)

What does it look like on mobile and desktop?

How should the UX behave?

Are the updated designs readily available?

How much time to add accessibility?

• E.g., invisible elements that screen readers should read out, can tab through all elements, UX for focused elements.

Does it work on all browsers we support?

Do other teams' CSS override ours in production? Could happen when multiple teams develop separately but their work is merged in prod.

Tests!

Reused code/components

Do we have to reuse code?

• How easy is it to edit and/or inherit for the new use case?

Is it legacy code?

• Do we have to update libraries? If yes, do we need regression testing?

Is it complex?

• E.g., deeply nested modules or 1000+ lines in the module.

Will regression testing be complex? E.g., if edited code touches 10 services, manual testing might be required in spite of extensive test coverage, especially when it's UI/UX.

Tests

TESTS. (I'm not great at this. 🤷🏻‍♀️)

Could add like 30-40% more time but totally worth it.

Meetings

Some days I code for like 30 min a day because of meetings. But the task in the agile scrum kanban tomato thingamajig backlog says the task I'm working on should take 2 hours. So then I end up spending maybe 4 days on the thing in total, because of meetings and complexities mentioned above. Not even exaggerating.

Buffer time

We're human. Procrastination, social obligations, and laundry are real.

And horror of horrors, equipment breaks down, WiFi fizzles out, botnets attack... 🙀

Build this in.

Workflow

All of this assumes that we already have in place a smooth company/department-wide workflow where business/commercial 📊 side snazzily breaks the product up into features, user stories, and/or tasks for easy bite-size dev consumption. Otherwise, that's a whole other thing.