In CREOTIVE we mostly use the agile methods and approaches in order to get the estimation more correctly.

Firstly, the project manager invite the developers/designers to the brainstorming corner and then read to them the requirements one by one. Each team member have a pair of Planning poker cards and for every requirement everyone drop the card in which is shown the estimate hour. Basically, poker planning uses Fibonacci sequence because the information that we obtain out of estimation grows much slower than the precision of estimation.

In every step team members discuss the hours if they are different from each other. For example if for a certain requirement, Developer A has dropped 8 hours card and Developer B has dropped 2 hours card then they will discuss why it takes so much time, Developer B will remind the team that a kind of requirements is done in the past and we can reuse it etc..

In the end of it, project manager collect the estimation for each task/requirements and provide to the client, team and anybody else involved in the project.

Estimation is easily one of the hardest topics in software engineering. I've tried to gather a couple of key points below:

• You can get exactly correct estimate only completing a task.
• Once you have completed a task, you have something to compare against.
• Estimates based on history and familiarness are more accurate than the ones you have to guess (uncertainty factor).
• The more uncertainty, the more room for error you should give. This is the reason why programmers often pad their estimates by multiplying them with pi. That takes uncertainty into account since there are always problems you fail to foresee.
• Especially junior programmers tend to give happy path estimates. That represents the shortest time it would take to complete the task. To get a more realistic figure, apply padding, or provide a range instead (min, max times, think standard deviation).
• Environmental factors can skew your estimates. Having dependencies on other tasks can lead to cascades that delay completion. If the team is too tired and/or there's technical debt, that's a multiplier you should take into account as well. Early on in a project it might be fast to get features done, but as technical debt is accrued, the progress will get slower. Strong development practices can counteract this.
• Time spent estimating is time not spent doing. Even the most thorough analysis won't get anything done. Instead you can try something more intuitive and adjust your estimates as information is gained. As I said early on, you have correct estimate only at the end. The degree in which your estimate can go wrong goes down as you get closer to completion.

Well, it's a little hard some times to make an approach, but it's more easy when more time you are in the project.

But for me, depend of the complexity and my experience with other similar task i can make a assessment of the total time of the task/project.

It's important to know if there is something new to you, something you know or if you resolved some similar task in the future, and know the advantages and disadvantages of that task.

It hard to make a exact appreciation of the total time, but when more task or issues in a project you do, more idea have on how many time take to resolve some task.

Our brain can estimate something and learn to be better at it next time. Intuition I think is the best weapon against estimating something. The surprising fact is that we wouldn't be completely aware of all the variables it considers while coming up with estimation.

In the end it's all guessing. Planning is guessing, do it more often!

The actual question one should ask is how frequent should you estimate. At dropx.io we follow a hybrid model of kanban with scrum meetings. It took me approximately 2-3 weeks to get an intuitive way of judgement for estimating a particular feature. These days it's easy to guess, but a deductive way of estimating would be to calculate individual velocities of all the team members and then we can definitely end up with a calculated guess(estimate).