3 ms·

That does depend upon your circumstances however. Often there are hard dates that can't be moved - because they are external to your organisation; the autumn T

by rahoulb 13y ago

That does depend upon your circumstances however. Often there are hard dates that can't be moved - because they are external to your organisation; the autumn TV schedule, or launching at a particular conference are two that have hit me in the past. Of course that does make the estimation a slightly different process - not "when will this be done" but "can you be ready before this date?"

sateesh 13y ago
but "can you be ready before this date? IMHO right answer to this is, Yes we can be ready but we might have to scale down on some of the features. But in reality most of the time only the initial 'Yes' part is heard with the caveats being ignored. As mentioned many a times it is "quality, features, schedule" and one can pick only two.
- jacques_chester 13y ago
  There's a lot of research in various industries that suggests quality is correlated with schedule. Poor quality -> more rework -> schedule blowout.
wpietri 13y ago
Sure. But instead of estimation, one can take a risk-management approach to that. For example, I'll get people to talk about everything they want. I'll put each thing on an index card. I'll have them lay the index cards out in order of importance (or ROI) on a big table. Then I'll ask: "Draw a line where, if you didn't get that far, you'd just bow out of the conference." Typically, that line is pretty early, 10-30% of what people would really like to have by the date. So then you take the backlog, make sure it isn't too lumpy, and start working. Just by measuring cards/week, you can pretty quickly know whether you'll hit the date. And typically, the team will have something shippable well before the date. The question then becomes: when is the ROI for the next week's work going to be lower than the ROI for something else we might do? And that question ends up being pretty easy, because you've pushed the decision off until you have a lot more data.
- jacques_chester 13y ago
  That's one thing I really like about agile: putting work in order of value, not in order of build efficiency. It's a bit like nature-inspired computation approaches to problem solving. They tend to introduce a lot of overhead that more direct algorithmic solutions won't, but you can terminate them at any point and get something. That flexibility is often very useful.

by rahoulb 13y ago

sateesh 13y ago

but "can you be ready before this date? IMHO right answer to this is, Yes we can be ready but we might have to scale down on some of the features. But in reality most of the time only the initial 'Yes' part is heard with the caveats being ignored. As mentioned many a times it is "quality, features, schedule" and one can pick only two.

jacques_chester 13y ago
There's a lot of research in various industries that suggests quality is correlated with schedule. Poor quality -> more rework -> schedule blowout.

wpietri 13y ago

Sure. But instead of estimation, one can take a risk-management approach to that. For example, I'll get people to talk about everything they want. I'll put each thing on an index card. I'll have them lay the index cards out in order of importance (or ROI) on a big table. Then I'll ask: "Draw a line where, if you didn't get that far, you'd just bow out of the conference." Typically, that line is pretty early, 10-30% of what people would really like to have by the date. So then you take the backlog, make sure it isn't too lumpy, and start working. Just by measuring cards/week, you can pretty quickly know whether you'll hit the date. And typically, the team will have something shippable well before the date. The question then becomes: when is the ROI for the next week's work going to be lower than the ROI for something else we might do? And that question ends up being pretty easy, because you've pushed the decision off until you have a lot more data.

jacques_chester 13y ago
That's one thing I really like about agile: putting work in order of value, not in order of build efficiency. It's a bit like nature-inspired computation approaches to problem solving. They tend to introduce a lot of overhead that more direct algorithmic solutions won't, but you can terminate them at any point and get something. That flexibility is often very useful.