Планирования спринтов: практики для Agile-команд

Основы планирования

У толкового планирования спринта понятная схема: разбираем предыдущие спринты, трезво оцениваем силы команды и чётко формулируем, чего хотим добиться. Подробнее: Сервис для управления IT проектами.

1. Готовиться нужно до встречи. Product Owner приводит backlog в порядок и расставляет приоритеты как минимум за день до планирования. А команда разработки успевает прочитать пользовательские истории и задать вопросы, которые иначе всплыли бы посреди обсуждения.
2. Привычное правило по времени: два часа планирования на каждую неделю спринта. Для двухнедельного спринта это четыре часа, но на практике их лучше разбить на две встречи по два часа — так внимание держится дольше, чем за один затяжной марафон.

Подготовительный этап

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

• Definition of Ready (DoR) задаёт планку, до которой пользовательская история должна дотянуть, прежде чем попасть в спринт. У каждой истории — внятные критерии приёмки, оценка сложности и понятные зависимости от других задач. Махнёте на DoR рукой — и планирование превратится в хаос: вместо того чтобы планировать работу, команда будет выяснять, что вообще имелось в виду.
• Backlog refinement ведут постоянно, а не наспех перед самим планированием. Закладывать на это около 10% времени спринта — нормальная практика. Удобнее проводить короткие сессии refinement пару раз в неделю и понемногу разбирать истории на будущее, чем разгребать всё разом.
• Анализ velocity показывает, сколько команда реально способна вытянуть. Тут важна не только средняя скорость за последние 3–5 спринтов, но и то, что может её подкосить в ближайшем: отпуска, праздники, накопившийся технический долг или зависимости от соседей.

Сессии планирования

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

1. Команда вместе с Product Owner определяет цель спринта, под которую подтягиваются все взятые истории. Цель нужна конкретная, измеримая и понятная каждому. Пустая формулировка: «Улучшить пользовательский опыт». Рабочая: «Пользователь сможет зарегистрироваться через соцсети в один клик».
2. Команда разработки разбирает истории на задачи и оценивает их в часах. На этом шаге наружу вылезают скрытые сложности и зависимости, которых на уровне истории не видно. Любая задача — не больше 8 часов; всё, что выходит за этот предел, дробим на подзадачи.

Роли и ответственность

Планирование идёт гладко, когда каждый понимает свою роль и держится её рамок.

• Scrum Master ведёт встречу, следит за таймбоксами и помогает команде договориться. Он ничего не навязывает — задаёт верные вопросы и не даёт обсуждению уйти в сторону.
• Product Owner расставляет приоритеты в backlog и решает, какие функции делаем первыми. От него ждут, что он объяснит бизнес-ценность каждой истории и ответит команде разработки достаточно подробно, чтобы её можно было оценить.
• Команда разработки берёт на себя обязательство довести результат. Важно, чтобы это обязательство шло от самой команды, а не спускалось сверху: то, что люди пообещали сами, держит совсем иначе, чем спущенный план.

Частые ошибки

• Переоценка собственных сил — самая ходовая ошибка планирования. Команды раз за разом набирают больше, чем способны закрыть, особенно в начале проекта или на эйфории после удачного спринта. Правило простое: лучше взять поменьше и перевыполнить, чем нахвататься и не дотянуть. Невыполненные обещания бьют по доверию стейкхолдеров и гасят мотивацию на следующих спринтах.
• Нет запаса по времени — серьёзный просчёт в самой конструкции плана. Закладывайте 10–20% буферного времени на то, что прилетит сверху: непредвиденные задачи, баги, запросы поддержки. И не забивайте этот резерв дополнительными историями — он нужен ровно для того, чтобы поглощать незапланированную работу, которая есть в каждом спринте.
• Зависимости, которые проглядели, оборачиваются блокерами в середине спринта. Все внешние зависимости надо выловить и проработать ещё на планировании. Если задача завязана на другую команду или на стороннего поставщика, сроки согласуют до старта спринта и получают подтверждение.

Мониторинг процесса

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

Что смотреть:

• Точность оценок — насколько плановое время совпало с фактическим по каждой истории и задаче
• Процент закрытых историй — сколько из взятого в спринт реально дошло до финиша
• Сколько раз менялся состав спринта после планирования — это про устойчивость плана и ясность требований
• Время на само планирование — сверяем со стандартом, чтобы поймать хронический перекос в ту или другую сторону

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

Адаптация планирования

• Удалённым командам планирование приходится подстраивать под себя. Нужны нормальные инструменты для совместной работы, и кто-то должен следить, чтобы голос был у каждого, кто на связи удалённо. В распределённой команде несколько коротких сессий вместо одной длинной встречи стабильно дают и вовлечённость повыше, и результат получше.
• Крупным программам с несколькими командами нужна координация на уровне всей программы. Scrum of Scrums или SAFe (Scaled Agile Framework) дают готовый каркас, чтобы синхронизировать планирование спринтов там, где у команд общие зависимости.
• Проектам на сопровождении, где львиная доля спринта уходит на поддержку и правку багов, мощность под незапланированную работу надо резервировать явно. Привычная схема — отдать 30–50% спринта на поддержку, а остальное оставить на новые функции. Иначе поддержку молча списывают в накладные расходы, и поставка срывается.

Читайте также:

Про фреймворки управления проектами и баланс ограничений — в статье Треугольник управления проектами: объём, время, стоимость.

Про канбан-доски и наглядное управление рабочим процессом — в статье Доска Kanban: руководство по управлению процессом.

Про то, как Agile-команды держатся реальных потребностей пользователей с помощью персонажей, — в статье Agile Personas: улучшение разработки, ориентированной на пользователя. Больше об этом: Доска канбан.

Заключение

Хорошее планирование спринтов — это система. И привычка постоянно её докручивать, а не разбирать полёты задним числом. Ретроспектива как раз даёт такой механизм — на ней смотрят и на итоги спринта, и на то, как его планировали. Так само планирование попадает под ту же итеративную доработку, которую Agile применяет к продукту.