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

Если вы откроете Руководство по Scrum раздел Sprint Planning (Планирование спринта), то увидите много букв и мало того, что позволит вам найти ответ на вопрос "Как сделать Sprint Planning (Планирование спринта) эффективным". Если вы новичок и никогда не наблюдали и не проводили планирование, то этот набор букв вас ещё больше запутает.

Эта статья для тех, кто хочет разобраться как же эффективно проводить Планирование спринта: что делать, а чего лучше не делать. Несмотря на то, что в официальной версии Руководства по Scrum принято использовать английское написание Sprint Planning, в этой статье я буду писать для удобства по-русски: Планирование спринта.

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

Как понять, что элемент бэклога готов к планированию спринта? Для этого у Scrum-команды есть свои "Критерии готовности к взятию в Спринт" (DoR - Definition of Ready). Это своего рода ворота качества или фейс контроль.

Пример того, что может включать в себя DoR:

Зона внимания: Не увлекайтесь DoR, он не должен стать как самый строгий фейс-контроль в самом крутом клубе, он должен быть достаточным для того, чтобы Developers смогли взять на себя обязатесльства, т.е. дать обещание, что они выполнят то, что от них просят и сделают это в требуемом качестве.

О том, как подготовить элемент бэклога продукта готовый к взятию в спринт, вы можете узнать на нашем тренинге "Лидер управления бэклогом продукта"

Несмотря на то, что Руководство по Scrum говорит нам о том, что цель спринта вырабатывается на Планировании спринта, в реальности это не совсем корректно. Если Владелец продукта не будет сам понимать какую цель хочет достичь, то он не поймёт какие элементы бэклога необходимо подготовить к PBR, а затем уже к Планированию спринта. Поэтому первично цель спринта исходит от Владельца продукта, а после обсуждения с Developer-ами может быть скорректированной по ряду причин. Одна из них - невозможность взятия в работу всего объёма, который соответствует первоначальной цели.

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

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

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

В руководстве по Scrum сказано, что после того, как определились с целью необходимо ответить на вопрос "Что может быть готово в этом Sprint?" и только после этого переходить в "Как будет выполняться выбранная работа?".

Как же это происходит в реальности? А реальность такова, что Developer-ы не могут ответить на вопрос "Поместится ли всё запланированное в спринт или нет?" без ответа на вопрос "Как и кем будет выполняться выбранная работа?"

Если Developer-ы используют стори поинты и правильно собирают статистику по своей работе, то они хорошо понимают свою Velocity и набирают элементов бэклога столько, сколько позволяет их средняя, а после этого идут составлять план.

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

Зона внимания: К сожалению, довольно часто я вижу как в компаниях отказываются от саб-тасков и в итоге очень сильно парализуют работу Developer-ов, а также нарушают сбор статистики. Если вы используете Jira, то не надо мудрить или удалять то, в чём вы до конца не разобрались. В Jira есть логика: Эпик - это сущность, которая не помещается в спринт, она декомпозируется на более мелкие сущности User Story, Job Story, Tech Story и является контейнером, к которому эти сущности привязываются для того, чтобы понимать прогресс, туда же в дальнейшем могут привязываться Tech Debt (технический долг) и Bug (Бага, которая не была исправлена в течение спринта). Tech Story иногда в компаниях именуют просто Task, что тоже нарушает прозрачность. В бэклоге продукта у вас должно лежать 4 вида элементов: User Sory/Job Story, Tech Story, Tech Debt, Bug, но никаких задач вида sub-task, которые являются сущностями нижнего (третьего) порядка и входят в сущности второго порядка User Sory/Job Story, Tech Story, Tech Debt, Bug, которые в свою очередь входят в сущность первого порядка - Эпик.

Более подробно о том, как навести порядок в своём бэклоге продукта вы можете узнать на нашем тренинге "Лидер управления бэклогом продукта"

После того, как первичный план готов, Developer-ы могут проверить себя - успевают ли они всё сделать или нет - используя временную линию (Time line).

Когда каждый Developer отвечает на вопрос сколько потребуется времени для завершения работы другие могут задавать вопросы. Также на временной шкале можно увидеть нет ли где сильного каскада, когда один долго ждёт другого, а также нет ли где моментов, где один Developer долго будет справляться с задачей и ему нужна помощь, возможно данный элементы бэклога лучше отдать другому - более опытному. Также Developer-ы могут увидеть не произошло ли такого, что компетенция "тестирование" завалена и участникам команды совсем не остаётся времени на проверку, а тем более исправление багов.

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

Когда Scrum-команда владеет такой информацией, ей проще самой контролировать свою работу - именно этим Developer-ы занимаются на Daily Scrum (он же дейлик).

Зона внимания: Конечно же, у Developer-ов в процессе появляются новые sub-tasks и удаляются ненужные. Главное, не просите у них нарезать свои sub-tasks размером на один день, некоторые будут и два дня, такое бывает. Каждый Developer выстраивает свою работу так, как ему самому удобнее - это уже его поле деятельности.

Только после такого упражнения Scrum-команда может сказать себе, что планирование завершено, а Владелец продукта сообщить своим заказчикам над чем будет работать Scrum-команда и что планируют показать на Обзоре спринта. Если Владелец продукта делает это раньше, то он подставляет своих Developer-ов и таким образом теряет их доверие и мотивацию.

Несмотря на санкции, некоторые компании по сей день работают в Jira. Как бы не закидывали Jira разными 💩, она – меньшее из зол, по-сравнению с другими треккерами, думаю это поняли многие.

Если у вас Jira и вы используете sub-tasks по уму, то вы можете настроить свои доски от сущностей второго порядка (см. вставку выше) и тогда у вас будет доска, на которой видно какие работы ведутся по какому элементу бэклога продукта и ваши дейлики перестанут быть "расстрельными", когда вы идёте по людям, а станут эффективным взаимодействием вокруг элемента бэклога, который должен превратиться по итогу в готовый инкремент. Таким образом вы будете понимать прогресс по элементам бэклога, а не загруженность людей (с ней будет всё нормально).

Больше про то, как выстраивать процессы в Scrum-команде вы можете узнать в нашей Школе Скрам-мастеров