Если вы знакомы с проектом и разобрали что за баг, то оценить время на его устранение не проблема.
Если вы не знаете что это за баг, то это еще не баг а production issue, и происходит его investigation до того момента, пока вы не придумаете временный workaround, чтобы пользователи могли работать, потом вы найдете root issue, заведете баг и уже тогда оцените время на его исправление.
В общем для любого senior разработчика эти вопросы должны быть понятны и ясны. Менеджер не программист и не должен им быть, но разработка крупного продукта должна каким-то образом регламентироваться. Иначе зачем платить программисту зарплату, если он не знает год он будет устранять баг или день? Как тот, кто платит вам деньги, сможет понять а хватит ли у него денег, чтобы вы ему продукт вообще написали, если оценить длительность работы нельзя?
Поэтому нужно не возмущаться, а учиться планировать свою работу.
В большинстве случаев опытный разработчик дает довольно точные сроки. Ну а на нестандартные случаи всегда закладывается какой-то процент времени. Бывают случаи, которые нельзя решить месяцами и годами - такое обсуждается, находится обходной путь и так и живут.
Agile в этом плане удобен не только тем, что можно накидать себе задач на 2-3 недели и их решать, а тем, что каждые 2-3 недели можно посмотреть назад, и понять насколько хорошо ты оценил свои естимейты, и нужно ли в следующем спринте увеличивать или наоборот уменьшать время. И так каждый спринт - смотришь и улучшаешь навыки планирования и эффективность работы.
