4 ms·

I'm not saying you should refuse to estimate, I'm saying giving an accurate estimate is verging on the impossible. You can attempt to do it, but people shouldn'

by UK-AL 10y ago

I'm not saying you should refuse to estimate, I'm saying giving an accurate estimate is verging on the impossible. You can attempt to do it, but people shouldn't expect it to be accurate. I'm just saying they are probably way out, and probably arn't that useful compared to other methods of building software. A lot businesses people who get this, then ask why bother if they are going to be really inaccurate? Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. Or even better do the implement and feedback cycle continuously. If you are not happy on the progress of a feature, cancel it. Because you doing things in small intervals, and then adjusting. It won't go wildly of the tracks, before realising you have to adjust or cancel it.

jacques_chester 10y ago
> Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation. I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months. What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide. Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed. But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous. I'm not saying anything new here. But I understand better where you were coming from.

by UK-AL 10y ago

jacques_chester 10y ago

> Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation. I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months. What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide. Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed. But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous. I'm not saying anything new here. But I understand better where you were coming from.