Comments on: If estimation is harmful… then, what’s not?

By: Synesthesia » Links roundup for 2008-02-25

Synesthesia » Links roundup for 2008-02-25 — Tue, 26 Feb 2008 00:33:37 +0000

[...] If estimation is harmfulâ�¦ then, whatâ��s not? [...]

By: No More Iterations - Wayne Allen's Weblog

No More Iterations - Wayne Allen's Weblog — Fri, 01 Feb 2008 21:07:39 +0000

[...] Lean Software http://epistemologic.com/2007/05/12/estimation-considered-harmful/http://epistemologic.com/2007/05/14/if-estimation-is-harmful-then-whats-not/http://www.gigamonkeys.com/blog/2007/04/26/estimation-considered-harmful.htmlhttp://www.poppendieck.com/pipeline.htmhttp://www.agilemanagement.net/Articles/Weblog/StopEstimating.htmlhttp://www.agilemanagement.net/Articles/Weblog/AgileEstimating.htmlhttp://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/http://alistair.cockburn.us/index.php/Are_iterations_hazardous_to_your_project [...]

By: BlogReader

BlogReader — Mon, 21 May 2007 23:02:58 +0000

Another thing to watch out for is group think when estimating time. I’ve seen a lot of times when a list of tasks are on the board and one person says 3 days for their task (I find that if you say anything over 1 day then the task isn’t fine grained enough). Then suddenly everyone else is saying their task will take 3 days as that’s now the default “I’m pulling this out of thin air” number.

By: Amit Rathore

Amit Rathore — Mon, 21 May 2007 20:27:40 +0000

Bob,

I agree. Having both quantitative (hours, points, whatever) and qualitative (assumptions, risks) estimates is extremely valuable. This allows one to have an educated conversation with management/customers around why things are progressing the way they are.

Also, it makes it easy to mitigate risk – one can pick the top items from this list of issues, and write code/spike tools/whatever to reduce the overall risk.

So overall, I completely agree. Again the difference in my approach (and what I’ve used on my projects) is around how to project the completion date. I prefer to use real team velocity, instead of the hours and tasks based estimation.

In the end, agile is about what works in the situation you’re in, and about adjusting the process to suit the project, team and organization.

By: bob

bob — Mon, 21 May 2007 20:10:54 +0000

Mathias obviously has practical experience in the matter and he’s right do what he does.

That aside. I find that with work estimates, experience and best guesses are only as accurate as the weakest links. As you flesh out the requirements, take time to identify areas that’s you aren’t as comfortable with — technologies that you have little experience working with or are unsure about the implementation time. These are the places to spend time breaking them into hourly tasks and padding. Broad brush the items you’re comfortable with and get to work!

By: Mathias

Mathias — Mon, 21 May 2007 17:29:38 +0000

We use detailed estimates for all development tasks. Why? Well, too often your gut feeling of “3 months, give or take” will be received with “ok, do it but in 1.5 months”. Arguments like “umm, my estimate was based on 14 years of experience” usually falls on deaf ears. Regardless, it will be me and my team doing the overtime in the end…

To that end a detailed estimate, based on a detailed brief and a response-to-brief document where you identify everything that you can foresee there and then goes into an Excel spreadsheet. If the brief changes, so does the estimate. If the answer still is 3 months, and they still come back with “you have 1 month” you can cooly go to your machine, print out the spreadsheet, throw in front of them and say “ok, you tell me what I’m not doing”. In short, it gives you more ammunition. It also educates the non-developers on what actually goes into a project.

We then summarize everything down into hours. Those hours are then spread out over 6-hour days for the main project all developers are on, thus creating slack for meetings and other admin tasks that also are part of a normal work day.

Works perfectly for us.

By: Brian Mowbray

Brian Mowbray — Mon, 21 May 2007 16:36:42 +0000

I personally like the way Mike Cohn wrote about it in his “Agile Extimating and Planning” book. Chapter 6 is all about trying to acheive the correct balance when estimating. There is a graph that shows clearly the amount of effort put into estimating will be less accurate if too little effort is expended and is also shows a dimishing return if too much effort is expended.