4 ms·

Can a team/business do better by not estimating? No, you can't (or rather, I don't see how). As he said, the most reliable way around it is having someone on

Can a team/business do better by not estimating? No, you can't (or rather, I don't see how). As he said, the most reliable way around it is having someone on your team that's been through it before. Most don't, because the experience that implies is not easily obtainable (if it were this problem wouldn't be as endemic). An estimate makes the person (ideally team) think the solution through, which should (assuming the estimate has any semblance of realism) bring out at least a conceptual understanding of the scope (which bounds the idea). Estimation, unfortunately, comes with baggage. In the self-managing agile world we have today, the inexperienced devs facing this problem are the same ones that dislike design up front, and consequently a coherent estimate.

wpietri 13y ago
I think it depends on the context. At my last company, we dropped mostly estimating because it wasn't getting us much in the way of value. We had other things to make us think the solution through. It also let us give up some illusions: That there was a single right solution. That we could know the idea's bounds in advance. That we wouldn't learn anything important by releasing early and often. Of course, we were a startup. In that context, it's easier to see that neither the problem nor the solution is understood. But looking back on other projects, I think 90% of the time I've spent estimating was wasted. In the future I expect I'd only do estimates if a) there were a question about being able to meet a hard external deadline (as opposed to a made-up bullshit deadline, which is most of them), or b) we needed to choose between alternative paths that were large enough that handwave relative estimates wouldn't cover it.
- jacques_chester 13y ago
  A common mistake is thinking that you're not estimating. You are, you just don't have a conscious, measurable or repeatable method anymore. You're defaulting to ad hoc "expert judgement". The second common mistake is doing The Estimate. A single estimate at the start is always going to be wildly wrong. But that's when it's most needed. That tradeoff continues throughout a project, from which it follows that there should be many estimates.
  - wpietri 13y ago
    Yes, I mean formal estimation, and the waste I'm talking about is the difference between casual and formal estimation. And the risk, too. Everybody gets that a handwave is a handwave, but a great deal of shops think that once somebody puts a number down, it turns into a fact. I totally agree that if you do need serious estimates, doing them on a rolling basis is the only way to go. I'm personally a fan of the Extreme Programming approach to that. The beginning of the project is when you know the least, so any estimate then is guaranteed to be the worst possible one.

wpietri 13y ago

I think it depends on the context. At my last company, we dropped mostly estimating because it wasn't getting us much in the way of value. We had other things to make us think the solution through. It also let us give up some illusions: That there was a single right solution. That we could know the idea's bounds in advance. That we wouldn't learn anything important by releasing early and often. Of course, we were a startup. In that context, it's easier to see that neither the problem nor the solution is understood. But looking back on other projects, I think 90% of the time I've spent estimating was wasted. In the future I expect I'd only do estimates if a) there were a question about being able to meet a hard external deadline (as opposed to a made-up bullshit deadline, which is most of them), or b) we needed to choose between alternative paths that were large enough that handwave relative estimates wouldn't cover it.

jacques_chester 13y ago
A common mistake is thinking that you're not estimating. You are, you just don't have a conscious, measurable or repeatable method anymore. You're defaulting to ad hoc "expert judgement". The second common mistake is doing The Estimate. A single estimate at the start is always going to be wildly wrong. But that's when it's most needed. That tradeoff continues throughout a project, from which it follows that there should be many estimates.
- wpietri 13y ago
  Yes, I mean formal estimation, and the waste I'm talking about is the difference between casual and formal estimation. And the risk, too. Everybody gets that a handwave is a handwave, but a great deal of shops think that once somebody puts a number down, it turns into a fact. I totally agree that if you do need serious estimates, doing them on a rolling basis is the only way to go. I'm personally a fan of the Extreme Programming approach to that. The beginning of the project is when you know the least, so any estimate then is guaranteed to be the worst possible one.