5 ms·

I think the reason that estimating is hard is that no one ever returns to their estimates and tries to fix the estimates. What usually happens is that people th

I think the reason that estimating is hard is that no one ever returns to their estimates and tries to fix the estimates. What usually happens is that people throw out a number, mismanagers think that number is negotiable, and whether the project's completion is in any way related to the estimate - the estimate is forgotten. No one writes down "this is why I think the project will take X [time units]". And no one goes back to that estimate and says "I left Y & Z out of that estimate, I better include that next time." If you want estimates that have any relation to reality, your estimating process needs to have that sort of feedback. > When people saying that estimating is hard... I think they're referring to the sort where management negotiates the estimates, like you're haggling over something in the marketplace. If they have such a strong opinion about how long something should take, then asking you for estimates is setting you up for failure and blamestorming. "It’s one banana, Michael. What could it cost, $10?"

deleted 3y ago
[deleted]
SpaceNoodled 3y ago
I've streamlined the process, and just say that anything will take five days to complete.
sroussey 3y ago
Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur. Also, on the negotiation side of time it will take, I absolutely know for myself that I can code things fast and functional but a bit hacky, or beautiful and elegant and will take much longer. The negotiation should be about when to do which. At a higher level, you put your teams together within their temperaments in mind and match that to the work. Some code will be a nexus of changes and interaction with other code (invest early), and some code will get written once and never seen again (go fast and forget).
PH95VuimJjqBqy 3y ago
One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch". The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.
Joeri 3y ago
In my experience writing out assumptions together with estimates tends to improve estimate accuracy a lot, by challenging the assumptions (and estimates) more at estimation time, and making it more visible when changes occur at implementation time that impact estimates. As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.
madeofpalk 3y ago
One of the most productive teams I worked on spent time at the end of an iteration to look back on our previous estimates and re-estimate them. We got much better at estimating the remaining work we had, and knowing whether we would hit deadlines or not.

deleted 3y ago

[deleted]

SpaceNoodled 3y ago

I've streamlined the process, and just say that anything will take five days to complete.

sroussey 3y ago

Teams definitely refine and alter estimates as new knowledge of the problem space is discovered. It’s a management (and team) failure if this does occur. Also, on the negotiation side of time it will take, I absolutely know for myself that I can code things fast and functional but a bit hacky, or beautiful and elegant and will take much longer. The negotiation should be about when to do which. At a higher level, you put your teams together within their temperaments in mind and match that to the work. Some code will be a nexus of changes and interaction with other code (invest early), and some code will get written once and never seen again (go fast and forget).

PH95VuimJjqBqy 3y ago

One of the things that makes me so successful is that I always try and have a backup plan. "our goal is X, if we fail to meet that with approach Y then we'll use approach Z. Lets prepare for approach Z while we're also preparing for approach Y and evaluate and switch to approach Z as early as we possibly can. We still want approach Y so we'll continue working on it even if we start using approach Z to successfully launch". The issue is that there's a fluidity in that thinking that many many MANY technical people either don't have or don't employ.

Joeri 3y ago

In my experience writing out assumptions together with estimates tends to improve estimate accuracy a lot, by challenging the assumptions (and estimates) more at estimation time, and making it more visible when changes occur at implementation time that impact estimates. As for negotiating estimates down, it is up to technical leadership to refuse to do that. Not easy, but doable.

madeofpalk 3y ago

One of the most productive teams I worked on spent time at the end of an iteration to look back on our previous estimates and re-estimate them. We got much better at estimating the remaining work we had, and knowing whether we would hit deadlines or not.