Comments on: Five Points To Improve Your Estimation http://www.sharpdeveloper.net/content/archive/2008/03/28/five-points-to-improve-your-estimation.aspx C# articles and tutorials on SharpDeveloper.NET Mon, 12 Dec 2011 15:06:31 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Sameer http://www.sharpdeveloper.net/content/archive/2008/03/28/five-points-to-improve-your-estimation.aspx/comment-page-1#comment-44 Sameer Sun, 25 May 2008 09:09:00 +0000 http://migrate.sharpdeveloper.net/content/?p=208#comment-44 Interesting point, but hard to justify all that time to your manager :) Interesting point, but hard to justify all that time to your manager :)

]]> By: Lucas Goodwin http://www.sharpdeveloper.net/content/archive/2008/03/28/five-points-to-improve-your-estimation.aspx/comment-page-1#comment-43 Lucas Goodwin Sat, 24 May 2008 22:41:00 +0000 http://migrate.sharpdeveloper.net/content/?p=208#comment-43 The key to estimation is Requirements/Feature Lock Down. If the requirements and features aren't locked down for the current release cycle then you're dealing with a moving target and thus all estimates are worthless, unless they shift with the target, but then they wouldn't be useful estimates either. Without that feature lock-down I've found the best answer is to blow the task out of the water. WAY over estimate it (More then double what you think it'll take). I've found more often then not, that huge of-the-cuff estimate ends up being a lot closer to the real tasks needed time then seemed at first blush. I'd rather loss the work then take on a project doomed to fail before it started just because the resources weren't there to begin with. The key to estimation is Requirements/Feature Lock Down. If the requirements and features aren’t locked down for the current release cycle then you’re dealing with a moving target and thus all estimates are worthless, unless they shift with the target, but then they wouldn’t be useful estimates either.

Without that feature lock-down I’ve found the best answer is to blow the task out of the water. WAY over estimate it (More then double what you think it’ll take). I’ve found more often then not, that huge of-the-cuff estimate ends up being a lot closer to the real tasks needed time then seemed at first blush.

I’d rather loss the work then take on a project doomed to fail before it started just because the resources weren’t there to begin with.

]]>