Здравствуйте, дорогие друзья!

Сегодня поговорим о такой теме, как планирование спринта в Скрам. В 2018 году я уже писал статью на эту тему. Тогда я работал Скрам-мастером в Альфа-Лаборатории и у меня был опыт, которым я хотел поделиться.

Эта статья была долгое время в топе по просмотрам и лид-магнитом в мой блог. За все время публикации ее посмотрели 7,4 тысяч раз. И сегодня я хочу рассказать, как изменился мой опыт и подход к планированию спринта.

Почему эта статья будет вам полезна

Сразу важный дисклеймер. Первую статью я писал под большим впечатлением от Скрама и во многом всё же опирался на Скрам-гайд. То есть по сути пересказал, как надо проводить планирование спринта в теории.

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

Итак, погнали. Начнем с контекста.

Я пришел работать продактом в страховую компанию в июле 2024-го года. Мне поручили разработку нового личного кабинета авто юридических лиц. Когда я пришел, команда только набиралась и у нее был нулевой спринт. Что это значило на практике? У команды был резиновый спринт, в котором она занималась созданием и настройкой окружения. 

Мне очень повезло, я попал в команду, где все были синьорами. У нас был сеньёристый аналитик, бэкендер и фронт-ендер. Нам не хватало только тестировщика, но мы его активно нанимали.

Я начал с того, что сказал команде: “Ребята, в ближайший четверг мы стартуем первый спринт”. Почему именно четверг? Потому что в доках, которые я прочитал, было написано, что в компании спринты стартуют по четвергам, а заканчиваются по средам. Поэтому я решил вклиниться в общий ритм.

Итак, мы стартанули первый спринт. У нас к этому моменту была готова карта пользовательских историй и бэклог от бизнес-заказчиков. Даже было определено, в какой последовательности нужно делать первые пользовательские истории.

Еще один бонус состоял в том, что команда даже оценила эти первые пользовательские истории в человеко-часах. Так что действительно оставалось просто твердой рукой запустить первый спринт, что я и сделал. 

Прошло 15 месяцев и вот как сейчас выглядит план проведения планирования спринта:

1. Актуализировать статус текущих задач на доске.
2. Чекнуть выполнение целей.
3. Закрыть спринт.
4. Перенести незавершенные задачи в новый спринт.
5. Дополнить спринт новыми задачами.
6. Сформулировать цели на новый спринт.
7. Запустить новый спринт.

Этот план работает на отлично на практике. Всё очень структурировано, понятно и просто. Делай раз, делай два, делай три – и вот тебе результат.

В общем рекомендую попробовать.

Обжигающая правда

• Да, у нас может быть несколько целей. 
• Нет, мы не оцениваем задачи на планировании спринта. 
• У нас нет четкого понимания ёмкости спринта (посыпаю голову пеплом – мой фейл). 
• У нас понимание пропускной способности команды строится на статистике закрытых спринтов. 
• У нас в спринте больше задач, чем мы можем выполнить. 
• Я стараюсь полностью утилизировать ресурс команды, чтобы никто не остался без работы. 
• Я добираю задачу в течение спринта, если у кого заканчивается работа. 
• У нас есть Agile-коуч, но он настолько не в контексте и дает такие капитанские рекомендации, что скорее этим бесит, а не помогает.

Резюме

Может показаться, что у нас не идеальное планирование спринта. И это так. Я бы с удовольствием добавил оценку работы в стори-поинтах, определил бы пропускную способность команды и ёмкость спринтах. Еще я бы очень хотел внедрить какой-нибудь распиаренный инструмент приоретизации, например, RICE или ICE. Сейчас у нас приоретизация строится на моём понимании ожиданий стекйхолдеров и на завершенности задач. То есть сначала завершаем начатое, потом начинаем новое. Или первым делом устраняем блокеры, чтобы можно было завершить начатую работу.

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

В общем, налицо некий когнитивный диссонанс: у нас не внедрены какие-то лучшие Agile-практики, но при этом мы деливерим задачи в те сроки, которые обещаем. 

Что с этим делать, я пока не решил. Как только решу эти проблемы, напишу еще один пост 🙂

А на этом у меня всё! Увидимся в новых постах.

Ваш Игорь.