В фреймворке Scrum выделяются обязательные события, которые должна посещать команда. Одно из них — планирование спринта. На нём команда составляет план работ на следующий отрезок времени: отбирает задачи из бэклога продукта согласно цели и решает, как их выполнить.
Планирование спринта проходит до начала спринта, обычно в середине предыдущей итерации, но команда может следовать своему таймлайну и выбирать другое время проведения.
В планировании участвуют команда, scrum-мастер и владелец продукта, иногда приглашают сторонних экспертов.
Длительность планирования — 4 часа для двухнедельного спринта, 2 часа — для спринта продолжительностью неделю и так далее, пропорционально этим числам.
Вопросы на планировании спринта
Во время этого события команда должна ответить на следующие вопросы:
- Какую ценность можно добавить продукту за следующий спринт?
- Как организовать работу, необходимую для создания ценности?
Чтобы ответить на них, команда должна учитывать:
- бэклог продукта,
- последний инкремент продукта, т. е. его актуальное состояние,
- среднюю скорость своей работы,
- ограничения, наложенные бизнесом, или особые требования.
У каждого спринта должна быть цель. Цель спринта — это общая задача, которая будет выполняться в рамках этого спринта. Она опирается на бэклог продукта и должна отражать бизнес-ценность. В результате достижения цели проект получает значимое обновление.
Цель помогает отобрать User Story из одной области, направленные на создание одной бизнес-ценности, или реализовать один Epic.
Вопрос первый: что будем делать в этот спринт?
На этом этапе формируется цель спринта. Команда разработчиков должна полностью понять её, чтобы работать в одном направлении. Владелец продукта отбирает истории из общего бэклога, которые наиболее подходят цели и имеют высокий приоритет. Они не обязательно все войдут в бэклог спринта, но помогают прогнозировать функциональность.
Если формальной цели нет (бывает, что её никак не выделить), в спринт берутся самые приоритетные истории из бэклога.
Команда задает максимум вопросов владельцу, а он передаёт ей своё видение. Для поставки ценности нужно знать много условий: расширить историю, учесть дополнительные факторы, определить критерии приёмки.
И команда, и владелец продукта должны чётко понять, что означает «Done» для выбранных историй, то есть когда историю можно считать полностью готовой.
Вопрос второй: Как будет выполнена работа?
Когда цель спринта установлена, а элементы бэклога отобраны для спринта, команда решает, как будет создана новая функциональность. Это больше техническое обсуждение, поэтому на данном этапе присутствие владельца продукта не обязательно.
По нашей практике, в компании Realize, на этом этапе могут требоваться «приглашённые эксперты». Например, команды зовут более опытного разработчика из другой команды или ментора гильдии, чтобы определиться с незнакомой задачей.
Истории, отобранные на первом этапе, делятся на мелкие, измеримые части — таски. Для них определяется примерное время выполнения — не больше 12 часов на одну задачу. Если вышло много совсем мелких тасков, примерно в 0,5 поинта, это повредит работе, потому что уведёт команду в микроменеджмент.
Оценка проходит через покерное планирование или определяется другими способами, которые предложит scrum-мастер. Важно и разбивать, и оценивать истории, потому что так команда анализирует фронт работ: у истории могут обнаружиться дополнительные задачи, которые нарушат график спринта.
Затем истории собираются в бэклога спринта. В него могут попасть не все истории: команда учитывает свою производительность, чтобы не оставить незакрытые задачи к концу спринта. Иногда из-за этого может корректироваться цель или критерии приёмки.
Для каждой истории заполняется карточка. В ней указывается описание истории, критерии готовности (DoD), примечания, важность и оценка по времени.
В бэклог спринта также попадают задачи, которые появились на ретроспективе. Они связаны с организацией рабочего процесса, улучшением взаимодействий и другими подобными вещами.
В итоге формируется бэклог спринта — упорядоченный список требований и задач для достижения цели спринта. Это картина работы на следующий спринт.
Команда разработчиков в конце планирования даёт «реалистичные обязательства», что подготовит инкремент продукта к концу спринта и выполнит его цель. «Обязательства» были в ранней версии ScrumGuide, но некоторые менеджеры понимали их превратно. Теперь в гиде указано, что во время планирования спринта команда «прогнозирует свою работу».
Рекомендации для хорошего планирования
Планирование — сложный и ответственный момент, от которого зависит весь следующий спринт. Главное тут — понять друг друга и определиться с работой, но в этом и есть основная трудность. Мы собрали несколько вопросов и советов из своего опыта и от agile-гуру, чтобы провести удачное планирование спринта:
- Все отобранные в спринт истории приняты владельцем продукта, критерии готовности чётко определены?
- Команда понимает, что значит каждая задача? Scrum-мастер обязательно должен задать этот вопрос.
- Нет ли дублирующих задач? Закрепите стикеры на стене, чтобы представлять работу, и заново проверьте, не получилось ли похожих тасков, которые можно объединить.
- Оценки задач — это не метрики, это прогнозы. Scrum-мастер должен убедиться, что из-за оценок команда не попадёт под давление со стороны стейкхолдеров.
- Тем не менее, scrum-мастер должен собирать прогнозы команды и сравнивать их с фактической работой, чтобы помогать команде давать более точные оценки.
- Выбирая задачи с учётом Velocity, команда должна заранее прикидывать, кто будет их выполнять. Если скорость команды 40 SP, но 50% задач приходятся на единственного дизайнера, — это нереалистичные обязательства.
- Не нарушайте временные рамки собрания, следуйте ценности Scrum — фокусировке на деле. Чтобы не растягивать оценку и обсуждение, ограничивайте их по времени: используйте песочные часы или секундомер.
- Планирование проходит легко, если команда не пренебрегает грумингом. Тогда истории будут уже знакомы разработчикам, и они придут подготовленными к конкретному обсуждению.
Если планирование даётся совсем трудно, возможно, в scrum-процессе команды есть фундаментальные проблемы. Но даже когда прогнозы не сбываются, помните, что компании не стать Agile за день, точно так же, как и не принять Scrum за один раз. Если команда поддерживает ценности в основе гибких подходов, то качество наладится со временем: с опытом и сработанностью.
