Как мы используем систему учёта дефектов для ведения product backlog’а

Как мы используем систему учёта дефектов для ведения product backlog’а

Есть ещё одна непростая задача. С одной стороны, 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е). Считаем баги обычными историями.

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