|
|
|
|
|
|
by joezydeco
5550 days ago
|
|
|
Because estimates are not committments. http://cwd.dhemery.com/2003/08/estimates_are_not_commitments... "If you ask Fred, “When will you be done?” have you asked for an estimate or a commitment? What does Fred think you asked for? If Fred says, “Two weeks from today,” has he given an estimate or a commitment? What might happen if you want a commitment and Fred thinks you want an estimate? What might happen if you want an estimate and Fred thinks you want a commitment? How could you make it crystal clear whether you’re asking for an estimate or for a commitment? How could you make it crystal clear whether Fred is giving an estimate or a commitment?" |
|
|
I like to think of myself as someone who has a lot of common sense, but reading McConnell's "Software Estimation" made me feel like an idiot. He lays out the most important stuff right at the start of the book: an estimate is not a commitment is not a plan to meet a target. Reading this, I realized that where I work, the term "estimate" is often used to mean any one of those three things at different times, but most often is used to mean "commitment." Not knowing any better, I fell right in line.
McConnell's basic strategy for delivering an estimate (give a minimum, a maximum, and an "expected time") is great for so many reasons, but the reason I like it the best is for its communication value - by giving three numbers, none of them being an "I can have it done by..." number, you reinforce the idea that you are delivering an estimate and that the point of delivering that estimate is to help the project manager control the project. If it turns out that the PM is lazy and they really do just want a commitment ("sure, sure, whatever, when will it be done?!"), you can adjust your communication strategy accordingly.