3 ms·

There is just so much lost in that phone-tag of a conversation between the actual customer and the actual developer in the scenario I think you're describing.

There is just so much lost in that phone-tag of a conversation between the actual customer and the actual developer in the scenario I think you're describing. Agile estimating techniques seem to provide a reasonable level of expectation, while placing more importance on collaboration between the product owner and the developers. Once you add development managers, project managers (who are often re-estimating for you, adding or reducing a number to align with some other expectation) and a product owner who's only hearing numbers rather than the details, it's a very lossy conversation. How many estimates have you given where you wish you could have said "but if we just do it like this, it'll only take x% of the time", and how well was that communicated to your client? I just think software estimating as a way of holding a conversation about a product under development is unproductive at best, and often leads to an inferior product .

RiderOfGiraffes 16y ago
I'm sorry, but that meant absolutely nothing to me. Your final line was: > I think it's best to stop estimating and start shipping. My point is that when I need a broad plan of what to implement, how much scope to include, when something will be ready by, and how many people will be required, I need to estimate. Sometimes I need to do that before I get down to the nitty-gritty of the real design, real implementation and real details, so I need some rule of thumb to let me give broad ROM estimates. One of our major customers recently asked for a feature and my sales colleague asked how long it would take. We didn't really know what the customer thought they wanted, so I went into a huddle with my lead programmer and together we sketched a reasonable feature that seemed to match the requirement, and estimated about 4 days of actual coding. I went back and replied that it would be 5 weeks of work on this feature (4 x 6 days) and that, given other commitments, that would be about 3 months elapsed time (one programmer working 1/2 time). So that's 5 weeks NRE on this feature, 3 months to delivery. The feature was priced accordingly, and when the customer upped the priority we put a programmer on it full time. It was delivered to site and signed off 6 weeeks later. Sometimes you need to estimate. So, what was your point? ADDED IN EDIT: I am, by the way, quite serious about that question. For me, in my circumstances, I really, really need to estimate in broad outline and get it roughly right. I'd like to see a clear exposition of why you think what I do is wrong. Could you perhaps write a more considered piece on your blog and link to it?
- briandoll 16y ago
  I agree that this is a very good topic and I'll flesh out some thoughts and post them soon. I'll email you when it's up. Would love to continue the dialog!

RiderOfGiraffes 16y ago

I'm sorry, but that meant absolutely nothing to me. Your final line was: > I think it's best to stop estimating and start shipping. My point is that when I need a broad plan of what to implement, how much scope to include, when something will be ready by, and how many people will be required, I need to estimate. Sometimes I need to do that before I get down to the nitty-gritty of the real design, real implementation and real details, so I need some rule of thumb to let me give broad ROM estimates. One of our major customers recently asked for a feature and my sales colleague asked how long it would take. We didn't really know what the customer thought they wanted, so I went into a huddle with my lead programmer and together we sketched a reasonable feature that seemed to match the requirement, and estimated about 4 days of actual coding. I went back and replied that it would be 5 weeks of work on this feature (4 x 6 days) and that, given other commitments, that would be about 3 months elapsed time (one programmer working 1/2 time). So that's 5 weeks NRE on this feature, 3 months to delivery. The feature was priced accordingly, and when the customer upped the priority we put a programmer on it full time. It was delivered to site and signed off 6 weeeks later. Sometimes you need to estimate. So, what was your point? ADDED IN EDIT: I am, by the way, quite serious about that question. For me, in my circumstances, I really, really need to estimate in broad outline and get it roughly right. I'd like to see a clear exposition of why you think what I do is wrong. Could you perhaps write a more considered piece on your blog and link to it?

briandoll 16y ago
I agree that this is a very good topic and I'll flesh out some thoughts and post them soon. I'll email you when it's up. Would love to continue the dialog!