| I think the main thrust of the article is factually correct (you can't estimate the creation of something new), but I don't think that's a very satisfying answer because you can't do anything about it. In my opinion, the single biggest problem with developers doing estimates is that they think they're being asked for a commitment, or they are being asked for a commitment but the asker is calling it an estimate. This creates a large number of problems in expectations and communication, and it causes the whole project to break down. There are some things that can be done on a project to help improve communication about estimates, commitments and targets: - Ensure that estimates, commitments, and goals are understood to be three separate things. - Ensure that everyone knows the benefits and uses of estimates, commitments and goals, as well as the non-uses. This is doubly true for estimates: many people treat them as commitments, but in reality they are supposed to be indicators that can be used to help control a project and make it successful. - Encourage people to put effort into their estimates. Developers often don't like working on estimates because every minute they spend working on them (or on other stuff like timesheets and status reports) is a minute they could have spent thinking, designing and coding. Ensure that everyone knows that spending time on estimates and other activities is truly valuable to the project and the group, and helps ensure success. - Do everything possible to remove stress and pressure around estimates. Reinforce the idea that estimates are used to help steer the project to success, not to hold peoples' feet over the fire (if a PM is trying to shrink estimates or pointing to estimates after a project has started and saying "tasks x, y and z are late," they're doing it wrong). - Make it known that estimates are supposed to have some uncertainty. Don't accept or expect single-point estimates, and make sure the people delivering the estimates aren't pressured to do so. |