Команда разработки, работающая по классическому Scrum с двухнедельными спринтами, сталкивается с ситуацией: очередь готовых к работе задач («Ready») исчерпывается уже на третий день спринта из-за того, что часть задач оказалась проще, чем ожидалось. Формальное расписание Scrum не предусматривает нового планирования до конца текущего спринта — разработчики либо простаивают, либо начинают браться за задачи низкого приоритета, которые не должны были начинаться так рано. Фиксированный календарный ритм планирования не соответствует реальной, изменчивой скорости команды.
Планирование должно запускаться по событию — когда буфер готовых задач опускается ниже порога, — а не по произвольному календарному расписанию; синхронизация ритма планирования с реальной скоростью команды устраняет и простои, и переплакирование.
Происхождение и исследовательская база
Scrumban предложен Кори Ладасом в книге «Scrumban: Essays on Kanban Systems for Lean Software Development» (2009) как способ эволюционного перехода команд от Scrum к более гибкому, управляемому потоком процессу — методология сохраняет полезные элементы Scrum (роли, ретроспективы, определение готовности) при этом заменяя фиксированные итерации на непрерывный поток с явными ограничениями незавершённой работы по каждому этапу.
Ключевые идеи и принципы
Принцип: Планирование по триггеру буфера, а не по расписанию
Вместо планирования каждый фиксированный интервал (спринт), новое планирование запускается автоматически, когда число задач в буфере готовых к работе («Ready») опускается ниже заранее установленного порога («bucket size») — это гарантирует, что команда никогда не остаётся без задач и не планирует слишком рано, когда буфер ещё полон.
Принцип: Ограничение незавершённой работы (WIP limits) по этапам
Каждый этап потока (в работе, на проверке и т.д.) получает явное ограничение на число одновременно находящихся в нём задач — превышение лимита сигнализирует о заторе, требующем внимания команды прежде, чем начинать новую работу, что предотвращает распыление внимания на слишком много параллельных задач.
Принцип: Сохранение ритуалов Scrum, адаптированных под непрерывный поток
Ретроспективы и обзоры сохраняются, но проводятся по календарному расписанию (например, раз в две недели) независимо от событийного цикла планирования — это позволяет команде сохранить полезные практики рефлексии Scrum, отделив их от жёсткого цикла итеративного планирования.
Ограничения, слепые зоны и критика
Событийное планирование по триггеру буфера требует более дисциплинированного, непрерывного отслеживания состояния потока, чем предсказуемый календарный ритм Scrum, что может быть сложнее для команд, привыкших к чёткому ритму итераций. Метод также менее нагляден для внешних стейкхолдеров, ожидающих предсказуемых, синхронизированных со спринтами демонстраций результата.
Типовые ошибки
Ошибка 1: Порог буфера («bucket size»), запускающий планирование, не откалиброван под реальную скорость команды.
Порог установлен произвольно, без учёта реальной скорости выполнения задач командой, из-за чего планирование либо запускается слишком поздно (команда уже простаивает), либо слишком рано (буфер ещё не исчерпан).
Как избежать: Калибровать порог буфера на основе фактических данных о скорости команды и корректировать его по мере накопления опыта.
Ошибка 2: Лимиты WIP не соблюдаются или превышаются без реагирования.
Команда продолжает брать новые задачи в работу, даже когда лимит WIP по этапу уже превышен, что приводит к росту незавершённой работы, увеличению времени выполнения и снижению фокуса.
Как избежать: Строго соблюдать установленные лимиты WIP, останавливая начало новой работы при их превышении и фокусируясь на завершении уже начатых задач.
Главное, что нужно знать
Scrumban заменяет фиксированное расписание планирования Scrum на событийный триггер — новое планирование запускается, когда буфер готовых задач опускается ниже порога, а не по календарному циклу, — при этом сохраняя ограничение незавершённой работы (WIP limits) по каждому этапу потока из Kanban и ключевые ритуалы Scrum (ретроспективы), адаптированные под непрерывный поток. Это синхронизирует ритм планирования с реальной скоростью команды вместо произвольного календарного интервала.
План внедрения
Неделя 1: визуализировать текущий поток работы на доске с этапами.
Неделя 2: установить лимиты WIP по каждому этапу на основе текущей пропускной способности.
Неделя 3: определить порог буфера готовых задач, запускающий новое планирование.
Неделя 4: запустить событийный цикл планирования и адаптировать ритуалы Scrum под новый ритм.
Далее: регулярно калибровать порог буфера и лимиты WIP на основе фактических данных о потоке.
Книги по теме
Ladas C. — «Scrumban: Essays on Kanban Systems for Lean Software Development» (2009). Оригинальная работа, представившая методологию Scrumban.