Что такое ретроспектива спринта: форматы, этапы и как её провести

Вячеслав Степанов — проджект-менеджер, ментор · 25 сентября 2026

Ретроспектива — последняя встреча спринта и единственная, где команда разбирает не продукт, а то, как она работает. Проджект-менеджер ведёт её одной из первых, и от этого часа зависит, повторятся ли ошибки в следующем спринте. Ниже — что такое ретро, пять этапов встречи, популярные форматы, приёмы ведения и три шага после. Видео-версия — мой открытый урок, сразу ниже.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое ретроспектива

Ретроспектива (ретро, Sprint Retrospective) — последняя встреча спринта. Команда собирается, чтобы посмотреть, как она работала эти две недели: что помогло, что мешало и что взять с собой в следующий спринт. Это один из пяти ритуалов Scrum — вместе с планированием, дейликами, грумингом и демо; как они складываются в ритм спринта, я разбирал в статье про Scrum.

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

Главное правило ретро

У ретроспективы есть базовый принцип — Retrospective Prime Directive. Его сформулировал Норман Керт в книге «Project Retrospectives» (2001):

Смысл простой: ретро разбирает систему, а не ищет виноватых. Если дизайнер не успел с макетом, вопрос звучит так: «что в планировании привело к перегрузке и как распределить работу иначе?». Люди перестают бояться признавать ошибки — и проблемы наконец выходят на поверхность. Поэтому на ретро и не зовут руководителей: при начальстве за столом команда говорит только безопасное, и встреча превращается в театр. Ведущий проговаривает правило вслух в начале каждой встречи.

Пять этапов встречи

Классическую структуру предложили Эстер Дерби и Диана Ларсен в книге «Agile Retrospectives» (2006). Это пять фаз, через которые команда проходит за встречу:

• Открытие. Настроить команду на честный разговор: проговорить главное правило, спросить у каждого одним словом «как настроение?».
• Сбор фактов. Что случилось в спринте — цифры, события, статусы задач, без интерпретаций.
• Понимание. Почему это случилось: причины и связи. Здесь основная дискуссия.
• Решение. Конкретные шаги на следующий спринт — с ответственными и сроками.
• Закрытие. Короткие итоги, «одно слово о встрече», спасибо друг другу.

Перед встречей ведущий готовит «итог спринта»: сколько задач планировали, сделали и перенесли; где висели блокеры с дейликов; что пошло не по плану; и статус плана действий с прошлого ретро.

Форматы ретро и когда какой брать

• Хорошо / Плохо / План действий — базовый формат: что сохранить, что мешало, какие шаги сделать. Понятен всем и работает быстро; минус — со временем превращается в рутину.
• Start / Stop / Continue (Начать / Прекратить / Продолжить) — три вопроса о конкретных действиях. Хорош, когда команда потеряла ощущение, что может что-то изменить.
• Mad / Sad / Glad (Злит / Расстраивает / Радует) — эмоциональный срез. Помогает, когда в команде накопилось напряжение, но пользоваться им стоит редко: такие форматы легко скатываются в жалобы.
• Парусник (Sailboat) — ветер (что двигает вперёд), якорь (что тормозит), айсберги (риски) и остров-цель. Для взгляда на большой проект — примерно раз в квартал.
• 4Ls (Понравилось / Научился / Не хватило / Хотелось бы) — после спринта с новой технологией или новым процессом.

Правило ведущего: держать базовый формат по умолчанию и менять его раз в 4–5 спринтов. Новые вопросы вытаскивают новые темы — иначе команда начинает отвечать по шаблону.

Встречу удобно проводить на онлайн-доске вроде Miro: 7–10 минут каждый молча пишет стикеры, потом все по кругу их зачитывают, ведущий группирует дубли, команда голосует точками и обсуждает три самые важные темы. Так тихие участники высказываются наравне с разговорчивыми.

Как вести: пять приёмов

• Давать слово по кругу. Обращаться по имени — так каждый получает свою очередь и разговор идёт равномерно.
• Держать паузу. Задал вопрос — подожди секунд десять. Самое важное часто звучит именно в неловкой тишине.
• Переводить с человека на систему. «Разработчик не успел» превращается в «оценка оказалась заниженной — как оценивать точнее?».
• Вовлекать тех, кто молчит. Прямой вопрос «а ты как это видишь?» — молчание часто значит «неудобно перебивать».
• Останавливать эмоциональные споры. «Слышу, что тема болезненная — вернёмся к ней отдельной встречей» — и держать тайминг.

Что делать после ретро

• Протокол в тот же день. Итог спринта, «хорошо», «плохо», план действий — в базу знаний команды (например, в Confluence) и ссылкой в общий чат, пока всё свежо в памяти.
• Каждая строка плана — задача в трекере. С исполнителем, сроком и ссылкой на протокол. Строка в документе — ещё не работа; задача в Jira — уже работа.
• Проверка на следующем планировании. Пройтись по пунктам: сделано, в работе, забуксовало. Незакрытое переезжает в новый план.

Простая метрика зрелости команды — какая доля плана действий доводится до конца. Если из пяти пунктов закрываются четыре, ретро работает. Если один — оно превратилось в разговор без последствий.

Типичные ошибки

• Ретро как жалобная книга. Сорок минут перечисляют плохое, в плане два расплывчатых пункта. Лекарство — баланс «хорошо» и «плохо» и не меньше 20% времени на план действий.
• Ведущий говорит больше всех. Заполняет паузы и отвечает за команду — люди замолкают. Лекарство — паузы и раунды по кругу: команда говорит сама.
• План без ответственных. «Улучшить код-ревью» — кто и когда? Лекарство — у каждой строки имя и дата.
• Одни и те же проблемы каждый спринт. Лекарство — проверять план на каждом планировании и разбирать, почему пункт не сделан.
• Обвиняющий тон. Лекарство — главное правило в начале и перевод «с человека на систему» по ходу.
• Пропуск ретро «из-за релиза». Лекарство — помнить, что час раз в две недели — самая дешёвая защита от повторения тех же ошибок.

Частые вопросы