Comments on: Estimating Time http://www.baltdad.com/2009/05/estimation/ random stuff, mostly technology related Sat, 17 Apr 2010 03:32:08 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: andrew http://www.baltdad.com/2009/05/estimation/comment-page-1/#comment-15 andrew Tue, 12 May 2009 01:32:36 +0000 http://www.baltdad.com/?p=322#comment-15 Part of the goal with accurate estimating and scheduling is to avoid limping over the end of a milestone. When your estimate is too short you end up taking shortcuts to hit the date. This is when these late cycle bugs creep up (imo). You have to be customer driven to some extent. Especially when you're small and competing against companies that can out spend you. The key, in my mind, is balancing goals. There are times when infrastructure improvements, while not customer facing, must be given time. There are other times when customer needs must take precedence over internal work. Again, accurate estimates aid in scheduling these internal projects. If you have a track record of completing your work on/under estimate, then you're more likely to be given time to revamp something. Part of the goal with accurate estimating and scheduling is to avoid limping over the end of a milestone. When your estimate is too short you end up taking shortcuts to hit the date. This is when these late cycle bugs creep up (imo).

You have to be customer driven to some extent. Especially when you’re small and competing against companies that can out spend you. The key, in my mind, is balancing goals. There are times when infrastructure improvements, while not customer facing, must be given time. There are other times when customer needs must take precedence over internal work. Again, accurate estimates aid in scheduling these internal projects. If you have a track record of completing your work on/under estimate, then you’re more likely to be given time to revamp something.

]]> By: Dilbagh http://www.baltdad.com/2009/05/estimation/comment-page-1/#comment-14 Dilbagh Mon, 11 May 2009 21:00:07 +0000 http://www.baltdad.com/?p=322#comment-14 I think all these methodologies work best only when there are right people making decision. Only if progress is tracked, analyzed, and corrective action taken, estimation/execution can be improved. Two biggest factors causing delays may be: - Too many bugs caught late in the life cycle. Developers hitting the milestones with only base cases working. - "Customer Driven" companies let customer/sales drive deliveries, and let engg/QA retrofit project plan. To me as long as, each project is broken down to 2 week or less level with trackable milestones, milestones are well understood, and a tracking is provided, any tool will suffice. What I would like to see in a tool is some kind of post-analysis and recommendation. Every time there is a slippage, tool should allow one to put in reason of slippage and corrective action, generate a report in the end. If corrective action was not taken then suggest adding x factor based on past experience. I think all these methodologies work best only when there are right people making decision. Only if progress is tracked, analyzed, and corrective action taken, estimation/execution can be improved. Two biggest factors causing delays may be:
- Too many bugs caught late in the life cycle. Developers hitting the milestones with only base cases working.
- “Customer Driven” companies let customer/sales drive deliveries, and let engg/QA retrofit project plan.

To me as long as, each project is broken down to 2 week or less level with trackable milestones, milestones are well understood, and a tracking is provided, any tool will suffice. What I would like to see in a tool is some kind of post-analysis and recommendation. Every time there is a slippage, tool should allow one to put in reason of slippage and corrective action, generate a report in the end. If corrective action was not taken then suggest adding x factor based on past experience.

]]>