Что происходит, если фича не успела быть сделана в спринт и как переносится задача

Что проверяют

Вопрос не про Go, а про то, как вы живёте внутри процесса. Смотрят, понимаете ли вы, что спринт это обязательство по цели, а не по списку задач, и умеете ли говорить о срыве срока рано и спокойно.

Как отвечать

Короткая рамка. Незавершённая задача не переезжает вместе с потраченным временем: она возвращается в бэклог, переоценивается по остатку и берётся в следующий спринт по приоритету, а не автоматически. Частично сделанная работа не идёт в зачёт скорости команды и не показывается на обзоре спринта.

Дальше подчеркните, что главное происходит до конца спринта. Как только видно, что не успеваем, это выносится на ежедневной встрече, а не в последний день. Варианты обсуждаются вслух: урезать объём до работающего минимума, снять другую задачу, попросить помощи, договориться о сдвиге с владельцем продукта. Решение о содержании спринта принимает команда вместе с ним, а не разработчик в одиночку.

Со стороны кода полезно назвать, что вы делаете, чтобы перенос не был болезненным: режете фичу на вертикальные куски, каждый из которых сам по себе осмыслен, вливаете готовые части под флагом, не держите ветку живой неделями. Для сервиса на Go это обычно означает сначала контракт и обработчик с заглушкой, потом реализацию, потом оптимизацию.

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

Где спотыкаются

Отвечают, что спринт продлевают или добавляют пару дней. Длина спринта фиксирована, иначе теряется весь смысл ритма и накопленных оценок.

Сообщают о проблеме в день демонстрации. К этому моменту выбора уже нет, а вопрос как раз о том, умеете ли вы поднимать флаг заранее.

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