Когда переносите задачу из спринта в спринт, заведите себе привычку давать значащие ответы. Возьмите за пример хотя бы SMART. Из вашего ответа должно быть четко понятно: S - какой цели вы хотите достигнуть в следующем спринте (например, если задача полностью не реализуется) M - за какое время вы хотите получить конкретный результат (например, до 03.10 реализую изменения в блоке main, до 10.10 буду править легаси в каталоге) A - что вы конкретно планируете делать для реализации (например, попробую поправить модуль main, а если не получится, напишу в тех. поддержку 3 письма с разницей в 2 дня) R - что вы планируете делать, если все пойдет не по плану (если не получится, то имеет смысл отказаться от данной задачи в связи с ее экономической нецелесообразностью или можно предложить альтернативный вариант решения с написанием нового модуля и подключением его как сторонний микросервис) T - когда вы планируете отдать ожидаемый результат (например, послезавтра сможете потестить модуль main)

Это нельзя воспринимать как инструкцию, не все пункты нужны при переносе задач, все зависит от контекста. Но если использовать как рекомендацию, то можно избежать негатива, который приходит после частых ответов, подобных: - Запросили в тех. поддержке, ответа нет. - Не хватило времени (текучка, другая задача, начальник сменил приоритеты, земля вертелась быстрее обычного) - . (не знали что писать, просто сдвинули спринт)

Нормальный ответ может в разы снизить градус напряженности от заказчика, не получившего в обозначенный период долгожданную фичу.