> Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate.

> Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate. My new approach to this has been responding with another question: "How much time is the problem worth? What is the organisation willing to spend to get it solved?" If they can't even tell me how much the problem is worth, I have no chance of making good prioritization decisions. (At that point I usually have to get there incrementally, so I start asking, "if I got it to you next year, would that have been time well spent? Okay, how about next quarter, would it still be relevant by then or would it have lost more than it earns us?" If they tell me break even is at roughly 20 engineering days, then I can say something like, "there's an 80 % chance I can get it done by then. If I can down-prioritise this other thing that goes up to 95 %. How would you like to proceed?" The discussions get much more productive this way. And I get more information about how valuable the different problems are.