Notes on Estimates: I have found the Richter-Scale estimation technique explained here .Some key highlights from this article

Richter-Scale Estimation :

• Estimates come on a log scale - months , weeks , days , hours or minutes

• “hard/medium/easy” scale for each feature. Hard means a full dev for a full milestone. Medium means a full dev for two to three weeks. Easy means a full dev for two to three days. There are no in-betweens, no hard schedules.

• A good dev schedule simply lists the features to be implemented in each milestone. The “must-have” features go in the first milestone and usually fill it. Fill is based on the number of devs and the “hard/medium/easy” scale. The “like-to-have” features go in the second milestone. The “wish” features go in the third milestone. Everything else gets cut. You usually don’t cut the “wish” features and half of the “like-to-have” features until the second week of the third milestone when everyone panics

Risk Management

Dev costing and scheduling is not about dates or time. It is about risk—managing risk. We ship software to deliver the features and functionality that will delight our customers. The risk is that we won’t deliver the right features with the right quality at the right time. A good dev schedule manages this risk by putting the critical features first—the minimum required to delight our customers. The “hard/medium/easy” scale determines what is realistic to include in that minimal set. The rest of the features are added in order of priority and coherency.

Meanwhile, you are trying to manage risk. One of your risk factors is an overworked staff. Another is a hurried, poor-quality feature. Another is losing weeks of time when you could have had two or three devs or more senior devs working on a tough issue. You lose that time when your dev staff thinks their reviews revolve around hitting feature dates instead of helping you manage the risk to the product’s critical features.

When you make it clear to your dev team that the success of the product depends on your ability to manage the risk to critical features, everything changes. Sure, getting extra features is a nice bonus, but the key is the focus on communicating risk areas and working together to mitigate them.

When everyone understands the goal, everyone works better to achieve it.

Accuracy vs Precision Pick accuracy over precision when estimating dev tasks. Good reference

#noestimate movement

I do not think #noestimates is pragmatic in majority of situations , but had to include their manifesto because it’s pretty well written . here