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