Представьте два Sprint Review.

В первом Product Owner полчаса показывает слайды. На каждом – новая фича. Команда молчит. Стейкхолдеры вежливо кивают, но единственный вопрос в воздухе: “Мы свободны?”. Это демо.

Во втором Review начинают с Product Goal: “Мы хотим сократить время выплаты по заявке вдвое”. Команда показывает не только, что сделано, но и какие метрики сдвинулись, где гипотеза не взлетела и что они предлагают поменять в плане. Стейкхолдеры спорят, перетасовывают приоритеты, рождаются новые идеи. Это уже разговор о продукте.

Что превращает первое Review в скучное шоу?

  1. Отсутствие реальных решений
    Если в комнате нет людей, которые могут подтвердить или изменить курс, встреча автоматически превращается в отчёт. Обратная связь без решений – это просто мнения.
  2. Фокус на “что сделали”, а не “что узнали”
    Сильные команды приходят на Review с вопросами и выводами, слабые – со списком задач. Во втором случае фреймворк формально соблюдён, но обучение не происходит.
  3. Проваленный контекст
    Когда никто не вспоминает Vision и Product Goal, каждое демо выглядит как случайный кусок работы. Участники не могут связать его с результатом, который им нужен, – интерес падает.
  4. Ноль о пользователе
    Любая фича без данных – это мнение команды. Даже грубые сигналы уровня “5 клиентов согласились на ручной прототип” куда ценнее, чем “мы доделали API”.
  5. Невидимая власть
    Иногда Review скучный не потому, что команда “не умеет”, а потому, что решения давно приняты где-то ещё. Тогда честнее признать: у нас не Sprint Review, а витрина статуса.

Парадокс в том, что оживить Review можно не фокусом с фасилитацией, а вопросом: “Где здесь пространство для реального выбора?”.

Присоединяйся к общению с единомышленниками https://t.me/kanbanclub

Какой фактор сильнее всего убивает ваш Sprint Review?

  1. Команда не может принимать решения
  2. Review – это одностороннее демо
  3. Нет понятной связи с Product Goal
  4. Не показываем метрики и данные
  5. Приходят “не те” стейкхолдеры