Checklist to estimate time to make a thing
Tags: management
Published: 2021-07-16 08:13:26

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.