Upd. Добавлю контекста)

Вы же разработчика не бросаете на растерзание менеджеров. Перед своим уходом своего разработчика нужно погрузить в текущие задачи, добавить на необходимые встречи и т.д. Т.е. нужно все подготовить так, чтобы и.о. по минимуму трогали всякие управленцы, и он был сосредоточен на команде и предстоящем релизе. Т.е. и.о. работает в лайт режиме.

Обычно, это интересно коллегам. Но если нет, то могут просто по-дружески заменить, если в коллективе хорошие отношения.

Делегирование задач разработчику - так, чтобы окна помыть или забор на даче поправить, не бывает) Обычно я отправляю вместо себя разработчика, если вопрос и так его затронет и нужна его экспертиза или если это поспособствует его развитию.

Делегировать нужно аккуратно, тут я согласен.

Про признание авторов: знаете теорию публичного апи? Что оно зачастую используется не так, как задумано автором.

В оценку мы хорошо попадаем (хотя это зависит от качества аналитики, но, когда она приличная, попасть несложно), даже если делаем что-то новое. 90% точно попадаем или заканчиваем немного раньше. Тут мне также помогают коэффициент разработки и оценка покером со всей командой. Т.е. мы всей командой собираемся и обсуждаем пути решения фичи. Это особенно помогает, если проект большой и всего не знаешь о нем. Например, на обсуждении понимаем, что нам нужно для этой фичи сделать вот то-то и то-то, а тут другой разработчик говорит, что что-то подобное в проекте уже есть, посмотрите там-то и там-то.

Бизнесу неважно, сколько мы делаем за спринт, да. Скорость разработки, в моем случае, это фактура, с которой мы идем бизнесу, если нам нужно объяснить, почему мы не успеем выполнить задачи в желаемый бизнесом срок. Т.е. мы не просто голословно заявляем, что не справимся (и, возможно, нас стоит уволить :) ), а приносим данные, с которыми сложно спорить. А когда есть данные, всегда можно конструктивно обсудить пути решения. Также по этим данным можно принимать и другие решения, например, о расширении команды.

Оценка в SP хороша тем, что не требует деталей. И когда я работал без этапа системного анализа, оценивать в SP - это был единственный вариант. Я писал в статье, почему стоит включать системный анализ.

А когда он есть, уже есть возможность оценить именно в часах. А с оценкой в часах легко можно наполнить спринт и спланировать работу команды на диаграмме Ганта, а в SP я не знаю, как это сделать.

Также, когда у вас и фичи, и технические задачи, и баги в SP, сложно предоставить бизнесу информацию, а сколько же бизнес-задач делается за спринт. А когда вычитаешь SP для бизнес-задач из всех задач, то получаешь искаженное значение. И я ни разу не встречал бизнес, которому был бы интересен тех долг.

Поэтому у меня получился такой скомбинированный подход.