Когда я вижу технические истории подобные этой, я обычно задаю product owner’у вопросы вроде «Да, но зачем?». Я делаю это до тех пор, пока не проявится истинная причина появления истории (в приведенном примере — повысить скорость поиска событий в панели управления). Первоначальное техническое описание проблемы можно поместить в колонку с примечаниями: «Индексирование таблицы Events может решить проблему».
Как мы готовимся к планированию спринта
Не успеешь оглянуться — как наступил день планирования нового спринта. Мы не раз приходили к одному и тому же выводу:
Вывод: Убедитесь, что product backlog находится в нужной кондиции, прежде чем начинать планирование.
Что значит в нужной кондиции? Что все user story отлично описаны? Что все оценки трудозатрат корректны? Что все приоритеты расставлены? Нет, нет и ещё раз нет! Это значит:
• Product backlog должен существовать! (Кто бы мог подумать?)
• У каждого продукта должен быть один product backlog и один product owner.
• Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать.
a) Не волнуйтесь, если задачи с низким уровнем важности имеют одинаковые значения, скорее всего, они не попадут в текущий спринт, а, следовательно, не будут обсуждаться.
b) Все user story, которые, по мнению Product owner’а имеют гипотетическую возможность попасть в следующий спринт, должны иметь уникальное значение важности.
c) Уровень важности используется исключительно для упорядочивания историй. Т. е. если история А имеет уровень важности 20, а история Б важность 100, это означает что Б важнее A. Это не означает, что Б в пять раз важнее А. Если Б присвоить важность 21 — смысл не поменяется!