4 ms·

1. Have you done it before? If no, triple your estimate. 2. Do you know everything involved? If no, double your estimate. 3. Do you have someone that you will

1. Have you done it before? If no, triple your estimate. 2. Do you know everything involved? If no, double your estimate. 3. Do you have someone that you will ask questions of or pair with to get through difficult sections quickly? If no, add half to the estimate. 4. Does your team like to nit pick pull requests? Add half to the estimate. 5. Factor average weekly toil into the estimate. If you don't measure this, triple the estimate. This may seem like a really big estimate. But measure the estimate against the outcome and tell me I'm wrong.

falcolas 3y ago
All this while remembering that you will probably only get 4 hours a day to dedicate to the project. Between responding to emails and chats, paperwork, training, meetings, and context switching - your day will be half gone before you can even touch a project.
jgeada 3y ago
Estimating a project that doesn't have detailed scope and specifications is a bit like asking "how long is a piece of string". Asking for an estimate before knowing what it is you are building is canonical MBA widget production management. Numbers and dates unrelated to reality so the idiots with the power can put data into their spreadsheets and claim they're doing something. Software has nearly 0 reproduction costs, so by definition you'll (mostly) only write software for something that has not been done before. How long will it take to quantify the unknown?
- chasd00 3y ago
  what i do is break it into two projects. The first is a "discovery" project where you learn what you need to know to give an accurate estimate. You can usually get a discovery estimate in the ballpark by understanding how complex the ask is and how many people you're going to have to interview. Then you deliver the actual estimate along with all your evidence that will drive the scope definition.
- throwawaaarrgh 3y ago
  Sorry, I guess I wasn't clear; my suggestions are for when you already have scope and specifications. When you think you know what to do and how to do it, you can then add all the extra time to come to the "actual estimate".

falcolas 3y ago

All this while remembering that you will probably only get 4 hours a day to dedicate to the project. Between responding to emails and chats, paperwork, training, meetings, and context switching - your day will be half gone before you can even touch a project.

jgeada 3y ago

Estimating a project that doesn't have detailed scope and specifications is a bit like asking "how long is a piece of string". Asking for an estimate before knowing what it is you are building is canonical MBA widget production management. Numbers and dates unrelated to reality so the idiots with the power can put data into their spreadsheets and claim they're doing something. Software has nearly 0 reproduction costs, so by definition you'll (mostly) only write software for something that has not been done before. How long will it take to quantify the unknown?

chasd00 3y ago
what i do is break it into two projects. The first is a "discovery" project where you learn what you need to know to give an accurate estimate. You can usually get a discovery estimate in the ballpark by understanding how complex the ask is and how many people you're going to have to interview. Then you deliver the actual estimate along with all your evidence that will drive the scope definition.
throwawaaarrgh 3y ago
Sorry, I guess I wasn't clear; my suggestions are for when you already have scope and specifications. When you think you know what to do and how to do it, you can then add all the extra time to come to the "actual estimate".