4 ms·

Eh, I think there is two ways this can go. If you're really working with people who are 'so stupid' as to take estimates literally and make plans assuming guar

Eh, I think there is two ways this can go. If you're really working with people who are 'so stupid' as to take estimates literally and make plans assuming guaranteed success in those times, then you probably have other leadership/management/risk problems in your company and are doomed anyway. There are plenty of time where there's a little bit of managerial art to communicating estimates to customers and prospects. For example, if my devs say "October, the API will be available", I may share that with the client if I understand that in reality it will take the client a long time to actually start using that API in production. So I may say "Probably early November..." with the mutual understanding that that's when they'll begin to integrate but the thing may not actually be prod-ready from either of our sides till January. It's complicated!

toss1 5y ago
You are making the assumption that development estimates have anything to do with when management, sales, or customers decide that they need something. Even without mgt/sales over-promising stuff to customers based on wishful thinking and only wanting to say "Yes" to a stupid customer demand without even bothering to ask development/engineering, I've seen situations where the date is the date, period. I've been in plenty of situations where it doesn't matter - it's an event, scheduled years in advance, national television, and the show goes on at Monday 16:00 PDT, period. Scheduling estimates have nothing to do with it. Be ready and be there, or everyone gets nothing. The only question is: "Can the team do it?".