Как планировать спринт

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

Хотя компании проводят его по-разному, в Scrum есть базовые правила, которых стоит придерживаться. Мы подготовили инструкцию, как легко спланировать спринт, даже если у вас мало опыта работы с гибкими подходами.

Спринт — это короткий временной интервал (от 1 до 4 недель), с помощью которого можно разбить сложные проекты на понятные задачи.

Понятие «спринт» пришло из Scrum. Согласно отчёту State of Agile, это самый популярный фреймворк ― его используют 63% компаний, которые работают по Agile. И большинство из них отмечают высокую эффективность этого подхода.

Спринт состоит из нескольких мероприятий: планирование, ежедневные встречи (daily scrum, или «стендапы»), выполнение задач (сам спринт), обзор результатов (ревью) и подведение итогов (ретроспектива).

Планирование спринта — это встреча участников проекта перед началом нового спринта. На ней:

• Владелец продукта (Product Owner) оценивает продукт с точки зрения бизнеса, определяет приоритетные задачи и обсуждает с командой, можно ли их выполнить в течение спринта.
• Скрам-мастер (Scrum Master) помогает организовать процесс и следит за тем, чтобы он проходил по правилам фреймворка Scrum.
• Команда разработки (Developer Team) составляет список задач на спринт, оценивает трудозатраты и согласовывает следующие шаги с владельцем продукта.

По правилам фреймворка, на планирование недельного спринта команда должна потратить не более двух часов. А если цикл длится месяц — не более 8 часов.

Scrum предлагает гайдлайны, как проводить разные мероприятия, включая планирование спринта. Вот основные шаги.

Первая задача — собрать команду. На встрече должны присутствовать все участники проекта: разработчики, дизайнеры, тестировщики и другие специалисты, а также Scrum Master и Product Owner.

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

Product Owner исходя из приоритетов бизнеса или заказчика должен выбрать задачи из бэклога продукта — общего списка всех задач, необходимых для развития решения. Вместе с командой он определяет цель спринта — что конкретно нужно сделать за этот период. Это может быть запуск новой функции или исправление критичных багов.

Команда обсуждает задачи, которые помогут достичь этой цели. Так формируется бэклог спринта — список работ на ближайший период. Важно, что в Scrum нет привычного руководителя: команда совместно несёт ответственность за результат.

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

• Гайд по планированию спринта: кто участвует в процессе, какие шаги нужно выполнить на каждом этапе, как ставятся цели и задачи на спринт.
• Порядок распределения ролей: кто за что отвечает, включая роли Scrum Master, Product Owner и команды разработчиков.
• Политики завершения задач (Definition of Done, DoD): какие условия должны быть выполнены, чтобы задача считалась завершённой.

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

• Шаблоны для User Stories или задач ― они помогут участникам правильно документировать требования и ожидания пользователей.
• Регламенты сдачи выполненных задач ― содержат информацию о процессе передачи готовой работы, проверках и ответственных за приёмку задач.

Minerva Knowledge ― это система управления знаниями полного цикла для быстрого решения инцидентов и повышения качества релизов.

С её помощью можно не только организовать совместную работу команды, но и решить вопрос доставки знаний до сотрудников. Например, благодаря Minerva Copilot, который встраивается в тикетную систему и ускоряет решение запросов с помощью рекомендаций и генеративного AI.

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

При выборе задач для спринта нужно учитывать технический долг и возможные ограничения. Если команда загружена на 100%, не останется времени на рефакторинг кода или устранение ошибок. Это может снизить качество продукта. Также в случае отпуска или больничного одного из членов команды его задачи некому будет подхватить. Поэтому важно заранее договориться с владельцем продукта о том, чтобы оставить 15-20% времени свободным.

Как оценивают задачи по Scrum?

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

1. Оценка в сторипоинтах

Story points, или сторипоинты — это способ измерять трудоёмкость задач. Они не привязаны ко времени и показывают, сколько усилий потребуется для выполнения работы с учётом рисков. Более сложные задания получают больше сторипоинтов, а простые — меньше.

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

Пример. Задача «исправить баги в интерфейсе» может быть оценена в 2 сторипоинта. А задание «разработать новую функцию» — в 8 сторипоинтов, если она требует больше работы.

2. Оценка в трудозатратах

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

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

Пример. Задача «провести код-ревью» может быть оценена в 3 часа. А задание «разработать API» — в 3 дня, если для выполнения нужно больше времени и ресурсов.

Фиксировать, что влияет на выполнение задач, можно в базе знаний. Например, документировать статусы задач, которые не выносят на обычную скрам-доску, такие как внутренние задержки или проблемы с подрядчиками.

Так со временем в системе управления знаниями накопится опыт сотрудников и кейсы по решению задач. Это поможет не повторять ошибки и непрерывно повышать эффективность спринтов.

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

• Backlog (бэклог) — список всех задач на спринт.
• To Do (к выполнению) — задачи, которые нужно сделать.
• In Progress (в работе) — задачи, которые выполняются в данный момент.
• Done (готово) — завершённые задачи.

Для каждого задания создаётся карточка, где указываются дедлайн, исполнитель и текущий статус.

Визуализировать план удобнее с помощью цифровых сервисов.

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

• Ставить чёткую цель. Команда должна понимать, что именно нужно достичь. Для этого можно использовать подход SMART (Specific, Measurable, Achievable, Relevant, Time-bound), который применяют в управлении проектами. Это означает, что цель должна быть конкретной, измеримой, достижимой, релевантной и ограниченной по времени.
• Учитывать мнение команды. Если задачи и сроки определяются без участия тех, кто будет выполнять работу, это может вызвать конфликты и снизить мотивацию конкретных сотрудников. Поэтому очень важно создать культуру доверия и открытости внутри команды.
• Расставлять приоритеты. Не все задачи одинаково важны. Сначала стоит решать те, которые имеют наибольшую ценность для бизнеса или продукта.
• Быть реалистичными. При планировании объёма задач важно учитывать реальные возможности команды, чтобы избежать перегрузки и поддерживать стабильный темп работы.

Для удобства можно использовать чек-лист — на какие вопросы должны быть получены ответы в ходе планирования спринта:

1. Какая главная цель у текущего спринта?
2. Как эта цель двигает проект вперёд?
3. Какие задачи самые важные?
4. Реально ли выполнить все задачи за спринт?
5. Хватит ли команде времени и ресурсов?
6. Есть ли неопределённости или риски по задачам?
7. Нужно ли ждать завершения других задач?
8. Нет ли перегруженности у отдельных членов команды?
9. Понятны ли критерии «готово» для каждой задачи?