13:00–13:30. product owner разъясняет цель спринта и рассказывает про бизнес-процессы из product backlog'a. Обсуждается время и место проведения демо.

13:30–15:00. Команда проводит оценку времени, которое потребуется на разработку бизнес-процессов и, при необходимости дробит их на более мелкие. В некоторых случаях product owner может изменить приоритет их исполнения. Выясняем все интересующие нас вопросы. Для наиболее важных заполняем поле «Как продемонстрировать».

15:00–16:00. Команда определяет набор user story, которые войдут в следующий спринт. Чтобы проверить насколько это реально, вычисляем производительность команды.

16:00–17:00. Договариваемся о времени и месте проведения ежедневного Scrum'a (если они изменились по сравнению с прошлым спринтом). После чего приступаем к разбиению user story на задачи.

Наличие расписания ни в коем случае не подразумевает наличия жестких ограничений. В зависимости от того, как проходит встреча, ScrumMaster может увеличить, или уменьшить продолжительность каждого этапа.

Одна из основных задач планирования спринта — это определение даты демо. А это значит, что вам придётся определиться с длиной спринта.

Какая же длина оптимальна?

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

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

В основном короткие спринты больше нравятся product owner'y, а длинные — разработчикам. Поэтому длина спринта — это всегда компромисс. Мы долго экспериментировали и выбрали нашу любимую длину: 3 недели. Большинство наших команд (но не все) используют трёхнедельный спринт. Достаточно короткий, чтобы предоставить адекватную корпоративную «гибкость», но в тоже время достаточно длинный, для того чтобы команда смогла достигнуть максимальной производительности и успеть решить все вопросы, которые возникнут по ходу спринта.

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

Однако, как только вы найдёте подходящею длину, надолго зафиксируйте её. После нескольких месяцев экспериментов нам подошла длина в 3 недели, поэтому теперь мы следуем этому правилу и используем трёхнедельные спринты. Иногда спринт будет казаться слишком длинным, иногда — слишком коротким. Но сохранение фиксированной длины спринта позволяет выработать корпоративный ритм, в котором все чувствуют себя достаточно комфортно. К тому же исчезнут споры, насчёт даты релиза, так как все знают, что как ни крути, а выпуск новой версии продукта каждые 3 недели.

Это случается практически всегда, когда в ходе нашего планирования я задаю вопрос: «Итак, какова же цель спринта?». Все начинают смотреть на меня удивлёнными глазами, а product owner — морщить лоб, почёсывая свой подбородок.

Почему-то сформулировать цель спринта бывает довольно непросто. Но я до сих пор убеждён, что усилия, потраченные на попытки сформулировать цель, оправдывают себя. Лучше паршивая цель, чем её отсутствие. Например, цели могут быть следующие: «заработать больше денег», «завершить три истории с наивысшими приоритетами», «удивить исполнительного директора», «подготовить систему к бета-тестированию», «добавить возможность администрирования» или что-нибудь в этом духе. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не в технических терминах. То есть языком, понятным даже людям вне команды.

Цель спринта должна отвечать на главный вопрос «Зачем мы работаем над этим спринтом? Почему мы все просто не уйдём в отпуск?». На самом деле, самый простой способ вытянуть цель спринта из product owner'a — напрямую задать ему этот вопрос.

Целью должно быть что-то, что не было ещё достигнуто. «Удивить исполнительного директора» может быть неплохой целью. Но только не в том случае, когда он и так в восторге от текущего состояния системы. В этом случае, все могут просто собраться и пойти домой, а цель спринта всё равно будет достигнута.

Цель спринта может показаться слегка глупой и надуманной на протяжении всего планирования. Но чаще всего, основная её ценность начинает проявляться к середине спринта, когда люди начинают забывать чего они хотят достичь в этом спринте. Если у вас работают несколько Scrum-команд (как у нас) над разными продуктами, очень полезно иметь возможность просмотреть список целей спринтов для всех команд на одной wiki-странице (или ещё где-нибудь), а также вывесить их на видном месте, чтобы все (а не только топ-менеджеры) знали, чем занимается компания и зачем!

Основное в планировании спринта — процедура выбора историй, которые войдут в спринт. А точнее, выбор историй, которые нужно скопировать из product backlog'a в sprint backlog.

Взгляните на картинку. Каждый прямоугольник представляет собой историю, расположение которой соответствует уровню её важности. Наиболее важная история находится наверху списка. Размер истории (т. е. количество story point’а) определяет размер каждого прямоугольника. Высота голубой скобки обозначает прогнозируемую производительность команды, т. е. количество историй, которое команда собирается завершить в следующем спринте.

Честно говоря, sprint backlog — это выборка историй из product backlog'a. Он представляет собой список историй, которые команда обязалась выполнить в течение спринта.

Именно команда решает, сколько историй войдёт в спринт. Ни product owner, ни кто-нибудь ещё.

В связи с этим, возникают два вопроса:

1. Каким образом команда решает, какие истории попадут в спринт?

2. Как product owner может повлиять на их решение?

Начну со второго вопроса.

Допустим, на планировании спринта возникла следующая ситуация:

Product owner’а разочаровал тот факт, что история «Г» не попадает в спринт. Что он может сделать в ходе совещания?

Второй вариант — изменение объёма работ: product owner начинает уменьшать объём истории «А» до тех пор, пока команда не решит, что историю «Г» можно втиснуть в спринт.

Первый вариант — изменение приоритетов. Если product owner назначит истории «Г» более высокий приоритет, то команда будет обязана включить её в спринт первой (исключив при этом историю «В»).

Третий вариант — разбиение истории. Product owner может решить, что некоторые части истории «А» не так уж и важны. Таким образом, он разбивает историю «А» на две истории «А1» и «А2», а затем назначает им разный приоритет.

И так, несмотря на то, что в большинстве случаев product owner не может контролировать прогнозируемую производительность, у него существует множество способов повлиять на то, какие истории попадут в спринт.