I Classic techniques of assessment development:
1) Poker estimate:
A team meets to listen and discuss tasks. Everyone gives a quote and authors of the largest and the smallest estimations should tell as much as they can about those opinions. The discussion ends when everybody accepted the final opinion.
2) Compare with similar tasks:
A team looks for similar projects and tries to compare them taking into account complexity and peculiarity factors. It may be effective but sometimes results are extremely incorrect.
3) Bottom-up & top-down:
At first, a team has to decompose task to subtasks and estimate them separately. The second step is to sum subtasks' estimate and compare the result with the whole prognosis. In case of a huge gap, re-estimate.
4) External expertise:
Ask someone from another department for his or her opinion and compare it with your estimation.
II Invite management
5) Don't forget about risks:
The most difficult and the most incomprehensible parts of a project are the riskiest ones, so management should add them to decomposed tasks to prevent forthcoming issues. Risks usually take up to 15% of the whole estimate, but they could rise to 20, even 25%.
6) Lack of resources:
Usually, we believe that we can use 100% of declared resources, but in fact, only 80% is available. It means that a team works 32 hours a week instead of 40. So, a manager has to keep in mind it while setting up deadlines.
7) Change of demands:
Customers are changing their demands all the time, so managers are able to upgrade estimates.
Statistics say that average developer spends only 55% of the time on coding and other 45% on different discussions. Further more, only 1/6 part of the whole time is usually spent on coding, and the longest process is testing and troubleshooting.
III Painful experience
9) It’s time to honestly admit:
Sometimes project managers have to tell customers about issues and delays. It's not comfortable for the both sides, but sometimes all of us have to do such things, and it would be much better to tell truth. A good manager explains all features and reasons of delay, sometimes tells about risks of forced work.
10) Average speed of work
Sometimes estimate is done by another person than would realize it, so PM should calculate the average speed of development to prevent overtimes and deadline violations.
Usually, a team needs day or two to prepare, before start development. Don't force your team to start faster if you don't want to spend more time on bug fixing.
Let a team communicate at last an hour per day! It's not a useless spent of time but a way to implement the best ideas.
13) Don't scare the customers!
Every customer is afraid of the huge estimation's gap, for example, 200-1000 hours. It would be better to speak about the higher first point if the team is not sure than show it to customers. Also, sometimes the best form of the estimate could be three figures: the lowest, the highest and the realistic.
14) Provide full pack of the documentation
Show your customers not only the end result but some information about. For example, analytics and testing results can be very spectacular.
That's all! Try to implement it in your workflow.