События Scrum: планирование, синхронизация, обзор и ретроспектива

Почему событий именно пять

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

Отсюда типичная ошибка: команда оставляет ежедневную встречу и планирование, а обзор и ретроспективу отменяет как «необязательные». Через два месяца выясняется, что процесс не меняется и результат никто не смотрит. Ритуалы остались, обратной связи нет.

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

Планирование: цель важнее списка

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

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

Итог встречи — цель цикла, состав работ и план, как их сделать, с которым команда согласна. Если согласия нет и объём «продавили», планирование не состоялось, и отвечать за срок будет тот, кто продавил.

Ежедневная синхронизация: 15 минут для команды

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

Формат «что делал вчера, что буду сегодня, что мешает» — подсказка, и держаться его буквально необязательно. Полезнее идти по работе, то есть смотреть на доску справа налево и разбирать задачи, которые ближе всего к готовности. Тогда разговор сам собой сходится на том, что застряло.

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

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

Уточнение бэклога: постоянная работа без слота в календаре

Уточнение бэклога в пять событий не входит: ни тайм-бокса, ни обязательного места в календаре у него нет. Владелец продукта и команда занимаются им между встречами, обычно от часа до двух за цикл; новой команде нужно больше. Цель простая. Верхние элементы бэклога надо довести до состояния, в котором их можно взять в работу без второго захода к владельцу продукта и без выяснений посреди планирования.

Признак того, что уточнения не хватает: планирование затягивается, потому что половину времени команда выясняет, что вообще имелось в виду. Признак избытка — подробно расписанные работы, до которых очередь дойдёт через квартал и содержание которых успеет измениться.

Слот в календаре тут заводят только тогда, когда иначе уточнение не происходит вовсе.

Обзор: показываем работающий результат

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

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

Незавершённую работу можно показать, но нельзя зачесть. Разница принципиальная: посмотреть на половину функции и получить раннюю реакцию полезно, зачесть её как результат цикла нельзя. Если «почти готово» начинают засчитывать, планка исчезает за два-три цикла, и критерии завершённости перестают что-либо значить. Незавершённое на конец цикла в следующий цикл автоматически не уезжает: оно возвращается в бэклог, и владелец продукта решает заново, брать его дальше или нет.

Ретроспектива: одна-две вещи, которые меняем

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

Главный признак рабочей ретроспективы — решения. Одно-два улучшения, у каждого ответственный и срок, следующая встреча начинается с их проверки. Список из десяти пунктов, к которому никто не вернётся, хуже, чем один выполненный.

Если из цикла в цикл всплывает одна и та же проблема и решений нет, она за пределами полномочий команды. Выносите такие вопросы наверх явно, с формулировкой и адресатом; переживать их заново каждые две недели бессмысленно.

События: длительность и результат

Что подготовить в Shtab к каждой встрече

Откройте перед каждой встречей нужный срез доски, и разговор начнётся с сути. Иначе время уходит на то, чтобы выяснить уже записанное. Ниже — что именно смотреть к каждому событию.

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