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

Ключевые идеи

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

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

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 применяет к продукту.

Рекомендуем почитать

"Scrum: The Art of Doing Twice the Work in Half the Time"

Показывает, как Scrum выстраивает работу команды, чтобы выдавать больше при предсказуемых обязательствах спринта.

"User Story Mapping: Discover the Whole Story, Build the Right Product"

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

"Essential Scrum: A Practical Guide to the Most Popular Agile Process"

Подробный справочник по структуре, ролям и практикам Scrum для тех, кто применяет фреймворк в повседневной работе.