Estimation is hard and often leads to unhappiness in teams. What techniques and guidelines do you follow when you are asked to estimate time for a new feature?
Make a rough estimate in your head (in less than 30 seconds) of how much you think it should take you to do a feature, then multiply that by 3 or 4.
Chances are, there will be some tiny details that take a lot more time than you originally thought.
If you think in your head that you should be able to do something in a week, say it will take you a month. If you get push back, resist, and in the worst case say you cannot reasonably do it in less than 3 weeks.
If you do finish it in one week as you expected (highly unlikely), well done: you've under-promised and over-delivered. Management should be happy.
Deadlines are toxic. Deadlines are never respected (400 % error) Deadlines are like playing poker (no way to be sure, even with KK) Estimation should be considered as what they are: a fu** estimation, not a truth. If management need it :
Else, ask the deadline. Close the discussion. If the feature is ready before the deadline, good. If it's not, what can you do ?
The rules of thumb: never sell what is not ready to be sell.
There are many methods for doing this, in fact there is a whole subject dedicated to this kind of estimation taught in colleges. People end up developing PER and Gantt charts to find estimates for deadlines and slack time for features. Pick any appropriate life cycle model and see what kind of evaluations help you out. Internet should be a good place to look for this.
Think of how long you think it'll take, then add at least double that on... That's what I do... I'd rather say its going to take longer and have it take way shorter than say it's going to be done in a week and it takes a month.
When it comes to software development, if you don't have an idea of how long something will take, you should do a test run. Time yourself and see how long it takes to finish a couple tasks. Use that timing to infer the overall time for all the tasks.
Ideally you have experience in something so you can look back and say "a simple landing page takes half a day" or "a Node-based CRUD takes a few hours". You'll be able to know the exact tools/frameworks you'll need and how to apply them, which makes the time estimation easier. Especially if you can extract components from previous projects.
For the unknowns, you think about it in terms of time. Set a broad goal, something giving yourself a bit of leeway. If you think it might take 1 week to figure it out, make it 2 weeks. You never know what nuance you'll trip up on during your learning experience.
I like the APE technique: Assess Product, then Evaluate Resources. Lay out a list of product features, evaluate what resources you have to build your product, and then estimate how much time you'll be able to get it done in.
A general rule of thumb: tell your employer/supervisor that you'll need slightly longer than you think you actually will, and tell those who work under you that they need to get it done slightly faster than you think they actually can.
Always provide padding, you never know when an issue might arise and take the project a little longer, try to break it down into smaller pieces. If you manage to do things quicker than your estimate everyone is happy, you're over delivering and not missing the deadline or under delivering.
The formula is very easy: probability x managers / teams x π :)
Joking aside. As almost everywhere the size matters here. Slice all projects and features into smallest possible pieces and estimate only the obvious ones for first while keep in blur all others and let the client/stakeholder/manager to clarify all question. Hopefully they do their job so when you finished your work there will be more clarified parts to estimate and continue with.
When you have to estimate the whole project then calculate a wide range (for example: 6-10 months) for all uncertain parts.
The other side of the coin is your experience. After you finish many projects you will see how much time required for which part. You will see because each and every new project will be 80% same as before.
BTW you can just follow any popular methodology and adopt the estimation techniques from there.
The more you know what you're doing, the better the estimate should be. Also padding time helps especially if you're venturing into a new domain.