Сколько было спринтов и каковы были их результаты

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

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

Как отвечать

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

Для Java-команды полезно показать, что входило в понятие «готово» кроме кода и ревью: миграции схемы, обратная совместимость API, фиче-флаги, порядок раскатки, чтобы старые и новые экземпляры сервиса могли работать одновременно. Это отличает разработчика, который планирует поставку, от того, кто закрывает тикеты.

Хорошо звучит и критический взгляд: например, что часть задач стабильно не влезала, и это чинилось дроблением на более мелкие, а не переработками.

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

Цифры из воздуха. «Восемь спринтов, производительность команды выросла на четверть» звучит как шаблон, и следующим вопросом будет, чем именно мерили. Если мерить было нечем, честнее говорить без процентов.

Второе: путают активность с результатом. Число закрытых задач не говорит ни о ценности, ни о качестве, и отвечать надо тем, что изменилось для пользователя или для системы.

Третье: пересказывают Scrum по учебнику вместо собственного опыта. Интервьюер знает, как процесс выглядит в теории, и ему интереснее, где он у вас ломался и что с этим делали.