Пример (диалог очень похож на то, что случилось во время одного из наших планирований спринта).
Команда: «У нас есть кое-какие внутренние технические работы, которые должны быть сделаны. Мы бы хотели заложить на это 10 % всего времени, т. е. снизить фокус-фактор с 75 % до 65 %. Это возможно?»
Product owner: «Естественно, нет! У нас нет времени!»
Команда: «Хорошо, давайте посмотрим на наш последний спринт (все бросают взгляд на график производительности на белой доске). Наша прогнозируемая производительность была 80, но реальная производительность оказалась 30, верно?»
Product owner: «Именно! У нас нет времени на внутренние технические работы! Нам нужен новый функционал!»
Команда: «Хорошо. Но причина ухудшения нашей производительность в том, что мы тратим слишком много времени на создание полной сборки для тестирования».
Product owner: «Ну и что?»
Команда: «А то, что производительность и дальше будет такой низкой, если мы ничего не сделаем».
Product owner: «Да … и что вы предлагаете?»
Команда: «Мы предлагаем выделить примерно 10 % следующего спринта на установку билд сервера и другие вещи, чтобы сделать интеграцию менее болезненной. Это, скорее всего, увеличит производительность всех последующих спринтов как минимум на 20 %!»
Product owner: «Серьёзно? Почему же мы это не сделали на предыдущем спринте?!»
Команда: «Хм… потому что вы не захотели, чтобы мы это сделали…»
Product owner: «О! Ммм…, ладно, тогда логично, если вы это сделаете сейчас!»
Конечно, есть и другой вариант: не вести переговоры с product owner'ом по поводу технических историй, а просто поставить его перед фактом, что у нас фокус-фактор такой-то. Но это не правильно даже не попытаться достичь компромисса.
Если product owner оказался сообразительным и компетентным (нам в своё время с этим действительно повезло), я бы рекомендовал информировать его как можно лучше и дать ему возможность определять общие приоритеты. Ведь прозрачность — это один из основополагающих принципов Scrum'а, верно?
Как мы используем систему учёта дефектов для ведения product backlog’а
Есть ещё одна непростая задача. С одной стороны, Excel очень хороший формат для product backlog’а. С другой стороны, вам всё равно нужна система учёта дефектов, и Excel здесь явно не тянет. Мы используем Jira.
Итак, как мы переносим задачи из Jira в планирование спринта? Не можем же мы просто их проигнорировать и сосредоточиться только лишь на историях.
Мы пробовали следующие подходы:
1. Product owner распечатывает самые высокоприоритетные задачи из Jira, выносит их на планирование спринта и вешает их на стенку с другими историями (неявно указывая их относительный приоритет).