Спринты и Agile-поставка в Plane: как настроить циклы и не срывать релизы

Спринты в Plane ведутся через циклы (Cycles): у цикла есть даты, набор задач и прогресс, а фичи, которые идут дольше одного спринта, собираются в модули (Modules). Чтобы релизы не срывались, нужно три вещи: фиксированная длина цикла, оценки до планирования и правило, сколько задач одновременно может быть в работе. Инструмент даёт структуру, а сроки держит дисциплина ритуалов.

Статья для тимлидов, продактов и руководителей разработки, которые переходят в Plane из Jira или впервые вводят Agile в команде. Ниже: как устроены циклы и модули, как настроить оценки и статусы, какие графики смотреть, как провести ритуалы в Plane, календарь двухнедельного спринта и ошибки, из-за которых релизы съезжают.

Циклы и модули: две оси планирования

Главная ошибка при переходе из Jira — пытаться найти в Plane точную копию спринта и эпика. В Plane две независимые оси.

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

Модуль — это результат. Фича, этап проекта или крупная доработка, которая может занять несколько циклов. Модуль показывает, сколько задач фичи готово и сколько осталось.

Задача входит одновременно в один цикл и в один модуль. На планировании вы берёте в цикл задачи из разных модулей, а на ревью продукта смотрите, насколько продвинулся каждый модуль. В 2026 году в Plane появились эпики как тип задачи и релизы (Releases), поэтому крупные инициативы можно описывать эпиком, а поставки фиксировать релизом. Для команды до 30 человек связки «цикл + модуль» обычно достаточно.

Если команда переезжает из Jira, учтите, что импортер переносит спринты, но эпики приходят обычным типом задачи. Их стоит сразу пересобрать в модули или эпики Plane. Подробный план переезда мы описали в статье о миграции с Jira на Plane.

Настройка проекта под спринты

Перед первым циклом настройте проект один раз, чтобы потом не менять правила посреди спринта.

1. Статусы. Пять-семь статусов достаточно: Бэклог, Готово к работе, В работе, Ревью кода, Тест, Готово, Отменено. Статус «Готово к работе» означает, что у задачи есть описание, критерии приёмки и оценка.
2. Оценки. Включите систему оценок в настройках проекта: баллы, категории или время. Продуктовым командам удобнее баллы или категории, командам с почасовыми договорами — время.
3. Типы задач. Минимум: история или фича, баг, техническая задача. Не заводите десять типов в первый день.
4. Метки. По компонентам или типу работ: бэкенд, фронтенд, мобильное, инфраструктура.
5. Длина цикла. Выберите одну длину и не меняйте её хотя бы квартал.
6. Определение готовности. Запишите на странице проекта, что значит «Готово»: код в основной ветке, тест пройден, задача показана продакт-менеджеру.

Оценки, ёмкость и ограничение незавершённой работы

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

Простой способ посчитать поправку: возьмите средний темп за последние три цикла и умножьте на долю доступных человеко-дней. Если в команде пять человек, цикл длится десять рабочих дней, а один разработчик уходит в отпуск на неделю, доступно 45 человеко-дней из 50, и в цикл стоит брать около 90% обычного объёма. Расчёт грубый, но он лучше, чем планирование «на ощущениях».

Правила оценки, которые работают:

• Оценивает команда, а не тимлид в одиночку.
• Задача крупнее половины цикла дробится до планирования.
• Баг без воспроизведения не оценивается и не берётся в цикл.
• Оценку не меняют задним числом, чтобы «красиво» закрыть цикл.

WIP, то есть количество задач в работе одновременно, — главный рычаг для сроков. Когда у разработчика пять задач в статусе «В работе», ни одна не доходит до теста к концу цикла. Ограничение мы вводим как правило команды: не больше двух задач «В работе» на человека и не больше трёх задач в «Ревью» на всю команду. Нарушения видно в представлении цикла, сгруппированном по исполнителям. Новую задачу берут только после того, как предыдущая ушла дальше.

Графики и дашборды: что смотреть во время цикла

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

Что смотреть и как читать:

• Прогресс цикла по дням. Если к середине цикла закрыто меньше трети, цикл под угрозой. Это повод для разговора на дейли, а не в последний день.
• Задачи без движения. Фильтр по задачам, которые давно не меняли статус, показывает, где команда застряла.
• Добавленные после старта. Каждая задача, добавленная в цикл после планирования, сдвигает что-то другое. Их стоит считать.
• Перенесённые из прошлого цикла. Если одни и те же задачи переезжают третий раз, они слишком большие или никому не нужны.
• Прогресс модулей. Показывает продакту, когда фича будет готова к релизу.

Сложные выборки удобно собирать на PQL, языке запросов Plane, похожем на JQL, и сохранять как представления.

Ритуалы в Plane

Ритуалы не меняются от смены трекера, но каждый получает своё место в инструменте.

Ритуал	Когда	Что делаем в Plane
Груминг бэклога	Середина цикла, 1 час	Представление бэклога с фильтром «без оценки», дробим и оцениваем задачи, переводим в «Готово к работе»
Планирование	Первый день цикла, 1–2 часа	Создаём цикл с датами, переносим задачи из «Готово к работе» до уровня ёмкости, проверяем связи blocked by
Дейли	Каждый день, 15 минут	Доска цикла, сгруппированная по исполнителям, смотрим заблокированные задачи и нарушения WIP
Ревью и демо	Последний день цикла	Список завершённых задач цикла, обновляем модули и релиз
Ретроспектива	После демо, 1 час	Страница ретро в Pages, улучшения оформляем задачами в следующем цикле
Релиз	По готовности модуля	Релиз в Plane со списком задач, заметки о выпуске на странице

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

Ретро стоит вести в Pages того же проекта: через полгода по ним видно, какие проблемы повторяются. Каждое решение ретро становится задачей с ответственным, иначе ретро превращается в разговор без последствий.

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

Две недели спринта по дням

Календарь для двухнедельного цикла, который мы используем как отправную точку. Под конкретную команду его сдвигают, но порядок сохраняют.

День	Что происходит	Что проверить в Plane
1, понедельник	Планирование, старт цикла	Цикл создан, задачи в пределах ёмкости, у каждой есть ответственный
2–4	Разработка, дейли	Нет задач без движения больше двух дней, WIP в пределах правила
5, пятница	Короткая проверка прогресса	Закрыто не меньше трети оценок, риски названы
6, понедельник	Груминг на следующий цикл	В «Готово к работе» есть задачи на следующий цикл
7–8	Разработка, ревью кода	Очередь «Ревью» не растёт
9, четверг	Заморозка новых задач, тест	Новые задачи в цикл не добавляются, всё недоделанное обсуждено
10, пятница	Демо, ретро, закрытие цикла	Незавершённые задачи разобраны явно, ретро записано, модули обновлены

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

Баги и срочные задачи внутри спринта

Спринт ломается не только из-за плохого планирования, но и из-за потока срочного: баги с продакшена, запросы продаж, просьбы руководителя. Запретить срочное нельзя, но его можно сделать видимым и ограниченным.

Работают три приёма:

• Резерв ёмкости. На планировании команда оставляет часть темпа свободной под незапланированные задачи. Сколько именно, видно по истории: посмотрите, сколько задач добавлялось в прошлые циклы после старта.
• Отдельный вход для заявок. Запросы от поддержки и продаж приходят через Intake, а не в личные сообщения разработчикам. Дежурный разбирает их раз в день и решает, что идёт в текущий цикл, а что в бэклог.
• Дежурный по багам. Один разработчик в цикле отвечает за срочные баги и берёт меньше плановых задач. Роль переходит по кругу, чтобы не выгорал один человек.

Каждая задача, добавленная в цикл после старта, должна вытеснять другую задачу сопоставимого размера. Если команда только добавляет и ничего не убирает, срыв релиза предсказуем заранее. Метка «добавлено после старта» помогает на ретро увидеть, сколько работы пришло снаружи и откуда.

Для команд, у которых срочного больше половины, Scrum с жёсткими циклами может не подходить. Им удобнее канбан-поток в Plane без циклов, с WIP-правилом и еженедельным релизом.

Типичные ошибки, из-за которых съезжают релизы

• Цикл как список желаний. В цикл берут всё, что хотелось бы сделать. Ёмкость не считается, и в каждом цикле остаётся половина задач.
• Автоматический перенос хвостов. Незакрытые задачи молча переезжают в следующий цикл. Команда перестаёт замечать, что планирует плохо.
• Модуль без владельца. У фичи нет человека, который отвечает за её готовность к релизу, и последние десять процентов работы висят месяцами.
• Оценки в днях без запаса. Оценка «два дня» не учитывает ревью, тест и созвоны.
• Задачи из чатов в обход цикла. Руководитель пишет разработчику напрямую, задача не попадает в трекер, цикл срывается по невидимой причине.
• Дейли как отчёт. Каждый рассказывает, что делал, вместо того чтобы обсудить, что мешает закрыть цикл.
• Смена длины цикла. Один цикл две недели, следующий три, потом одна. Темп становится несравнимым.

Контекст Казахстана. Многие команды распределены между Алматы, Астаной и удалёнкой, поэтому дейли и планирование проходят онлайн, а договорённости легко теряются в WhatsApp. Правило «задача существует только в цикле Plane» здесь важнее, чем в офисной команде. Закладывайте праздники в ёмкость: на мартовские дни с Наурызом и майские праздники цикл может потерять несколько рабочих дней. Если в задачах и вложениях есть данные клиентов и компании важно хранить их в Казахстане, ставьте self-hosted Plane на казахстанский сервер: облако вендора хранит данные за рубежом.

Если команда параллельно внедряет цели, циклы удобно связать с квартальными OKR. Как это сделать, мы разобрали в статье об OKR в таск-трекере.

Как мы это делаем

Мы начинаем с диагностики: смотрим, как команда планирует сейчас, сколько задач в среднем не закрывается в спринте, где теряются требования и кто принимает решение о составе релиза. Затем запускаем пилот с одной командой на два-три цикла в Plane, настраиваем статусы, оценки, представления и ритуалы и по итогам ретро правим правила. После этого схема переносится на остальные команды без изменений в базовых правилах.

Подробнее о том, как проходит внедрение, на странице услуги внедрения таск-трекеров Jira и Plane.

---

Источники. Тарифы и функции Plane: plane.so/pricing. Описание новых функций Plane: блог Plane. Исходный код Community Edition: github.com/makeplane/plane.

Термины простыми словами

Agile

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

Спринт и цикл (Cycle)

Фиксированный отрезок, обычно две недели, на который команда берёт определённый набор задач. В Plane спринты называются циклами.

Модуль (Module)

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

WIP-лимит

Ограничение числа задач, которые человек или команда держат в работе одновременно (Work in Progress). Чем меньше начатого, тем больше задач доходит до готовности к концу спринта.

Ёмкость и темп

Темп — сколько оценочных баллов команда в среднем закрывает за цикл. Ёмкость — сколько можно брать в следующий цикл с поправкой на отпуска и праздники.

Груминг бэклога

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

Дейли и ретроспектива

Дейли — ежедневная 15-минутная встреча о том, что мешает закрыть цикл. Ретроспектива — разбор после цикла: что улучшить, с задачей и ответственным на каждое решение.

Scrum и канбан

Scrum — работа фиксированными спринтами с планированием и демо. Канбан — непрерывный поток задач с лимитом незавершённой работы; подходит командам, у которых много срочного.