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

Сегодня я хочу поделиться опытом фасилитации планирования спринта в Скраме.

Материалы доступны в Онлайн-библиотеке Школы Канбана.

Когда в 2016-м году я пришел на работу скрам-мастером в Альфа-Лабораторию, я не знал, как правильно проводить планирование спринта и по-началу совершал много ошибок.

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

К написанию этого поста меня побудила работа с одной из команд клиента. Хотелось быстро и лаконично передать Скрам-мастеру, Команде разработки и Владельцу продукта опыт фасилитации встречи.

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

Первый опыт фасилитации данного события случился со мной в Альфа-Лаборатории. Я тогда только вошел в роль скрам-мастера и изучал скрам на практике. Спросить опыта было практически не у кого. Меня окружали такие же начинающие скрам-мастера. Мы выживали как могли 🙂

В нашей версии планирование спринта выглядело так:

1. Мы располагались возле проектора и ВКС рядом с Белой стеной.
2. Владелец продукта приносил на планирование спринта заранее подготовленный и оцененный список требований (элементов бэклога продукта).
3. Список элементов уже был отсортирован в приоритетном порядке.
4. По очереди команда разработки проходилась по каждому элементу и обсуждала, сможет ли она сделать его или нет с учетом текущих возможностей (отпуска, болезни).
5. Если ответ был утвердительный, то команда разработки брала задачу в бэклог спринта.
6. Если ответ был отрицательный, команда обсуждала, что можно сделать по этому элементу здесь и сейчас.
7. Владелец продукта отвечал на вопросы команды разработки, когда что-то было непонятно.
8. Под конец планирования мы проверяли, что набрали такой же объем задач, как и в прошлом спринте. А если наблюдалась разница между объемами, команда разработка принимала решение – оставить разницу или нет. Иногда команда брала больше, чтобы проверить свои максимальные возможности.
9. Иногда команда разработки спорила с владельцем продукта, так как он старался протолкнуть как можно больше задач в бэклог спринта.
10. Иногда мы формировали цель спринта.
11. Почти никогда мы не составляли план реализации элементов бэклога продукта, которые попадали в бэклог спринта.
12. Почти никогда мы не обсуждали, что необходимо сделать, чтобы реализовать инкремент.

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

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

Алгоритм планирования спринта

Проанализировав этот опыт и перечитав множество раз Скрам-гайд, я подготовил вот такой флип-чарт для скрам-мастера, с которым работал.

Она воспользовалась им на ближайшем планировании и рассказала, что он помог ей быстро объяснить всем участникам, что и как нужно делать.

Заключение

На сегодняшний день фреймворк Скрам остается ведущим и самым распространенным в больших компаний. Ежедневно одна треть посетителей блога приходит именно по запросу «планирование спринта».

Я понимаю, что не в каждой компании удасться выполнить все, что написано в алгоритме и провести условно идеальное планирование. Но может быть это вам и не нужно?

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

Мы, как агенты изменений, можем приблизить эту встречу к максимально идеальной. Но всегда стоит задавать себе вопрос: «Для чего мы это делаем?» И только получив честный ответ, двигаться дальше.

С вами был Игорь, удачного планирования!