2. Product owner создаёт истории, соответствующие задачам из Jira. Например, «Исправить самые критические ошибки отчётности в админке, Jira-124, Jira-126, и Jira-180».
3. Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор (например, 50 %), чтобы хватало времени на исправления. Затем, вводится предположение, что команда в каждую итерацию будет тратить определённую часть времени на ошибки в Jira.
4. Заносим product backlog в Jira (просто переносим из Excelе). Считаем баги обычными историями.
Мы ещё не определились, какой подход для нас самый лучший; в действительности он может отличаться в разных командах и меняться от спринта к спринту. Я больше склоняюсь к первому подходу: он прост и понятен.
Свершилось! Планирование спринта закончено!
Ух, я и не думал, что глава по планированию спринта будет такой длинной [4]! Полагаю, этот факт отражает моё мнение: планирование спринта — самая важная вещь в Scrum’е. Вложите побольше усилий в планирование — и всё остальное пойдёт как по маслу.
Планирование спринта прошло успешно, если все (и команда, и product owner) с улыбкой завершают встречу, с улыбкой просыпаются следующим утром и с улыбкой проводят первый ежедневный Scrum.
Затем, конечно, всё может пойти криво, но вы, как минимум, не сможете списать всю вину на планирование спринта: o)