Product owner: «Серьёзно? Почему же мы это не сделали на предыдущем спринте?!»

Команда: «Хм… потому что вы не захотели, чтобы мы это сделали…»

Product owner: «О! Ммм…, ладно, тогда логично, если вы это сделаете сейчас!»

Конечно, есть и другой вариант: не вести переговоры с product owner'ом по поводу технических историй, а просто поставить его перед фактом, что у нас фокус-фактор такой-то. Но это не правильно даже не попытаться достичь компромисса.

Если product owner оказался сообразительным и компетентным (нам в своё время с этим действительно повезло), я бы рекомендовал информировать его как можно лучше и дать ему возможность определять общие приоритеты. Ведь прозрачность — это один из основополагающих принципов Scrum'а, верно?

Есть ещё одна непростая задача. С одной стороны, Excel очень хороший формат для product backlog’а. С другой стороны, вам всё равно нужна система учёта дефектов, и Excel здесь явно не тянет. Мы используем Jira.

Итак, как мы переносим задачи из Jira в планирование спринта? Не можем же мы просто их проигнорировать и сосредоточиться только лишь на историях.

Мы пробовали следующие подходы:

1. Product owner распечатывает самые высокоприоритетные задачи из Jira, выносит их на планирование спринта и вешает их на стенку с другими историями (неявно указывая их относительный приоритет).

2. Product owner создаёт истории, соответствующие задачам из Jira. Например, «Исправить самые критические ошибки отчётности в админке, Jira-124, Jira-126, и Jira-180».

3. Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор (например, 50 %), чтобы хватало времени на исправления. Затем, вводится предположение, что команда в каждую итерацию будет тратить определённую часть времени на ошибки в Jira.

4. Заносим product backlog в Jira (просто переносим из Excelе). Считаем баги обычными историями.

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

Ух, я и не думал, что глава по планированию спринта будет такой длинной [4] ! Полагаю, этот факт отражает моё мнение: планирование спринта — самая важная вещь в Scrum’е. Вложите побольше усилий в планирование — и всё остальное пойдёт как по маслу.

Планирование спринта прошло успешно, если все (и команда, и product owner) с улыбкой завершают встречу, с улыбкой просыпаются следующим утром и с улыбкой проводят первый ежедневный Scrum.

Затем, конечно, всё может пойти криво, но вы, как минимум, не сможете списать всю вину на планирование спринта: o)

Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или — что ещё хуже — придумывать всякие ужасы про вас.

Мы для этой цели используем «страницу с информацией о спринте».

Иногда мы также добавляем к названию истории поле «как продемонстрировать»

Сразу же после встречи по планированию спринта эту страницу создаёт ScrumMaster. Он помещает её в wiki, и тут же спамит на всю компанию:

Кроме этого у нас есть «панель» в wiki, в которой содержаться ссылки на текущие спринты всех команд.

В дополнение ко всему этому наш ScrumMaster распечатывает страницу информации о спринте и вывешивает её на стену в коридоре. Таким образом кто угодно, проходя мимо, может взглянуть на эту страницу и узнать, чем же занимается наша команда.

Когда спринт подходит к концу, ScrumMaster напоминает всем про приближающуюся демонстрацию

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

Уже добрались до этой главы? Отлично!

Итак, мы только что закончили планирование и протрубили на весь мир про начало нашего новоиспечённого спринта. Теперь настал черёд ScrumMaster'а создать sprint backlog. Это необходимо сделать после планирования спринта, но до начала первого ежедневного Scrum’а.