Елена Гылыжова:
Бэклог — упорядоченный список известных требований к продукту, и владельцем этого списка является Продакт Оунер. Он распределяет задачи в бэклоге.
Бэклог живет вместе с продуктом — к последнему постоянно прилетают различные хотелки, фичи, требования. Планируется внедрить новую функцию, доработать уже существующую, исправить ошибки, провести исследования — вся эта информация должна быть где-то в одном месте. В бэклоге.
Бэклог доступен всем желающим: команде, заказчикам, Скрам-мастеру. Все должны понимать, куда движется продукт, какое его видение, какие приоритеты у Продакт Оунера.
Элементы бэклога должны быть написаны простым языком, максимально понятно, чтоб даже человек с улицы, прочитав, понял суть.
Обычно бэклог существует в формате списка. То, что вверху, — наиболее важно для продукта, с этим работает непосредственно Продакт Оунер.
В каком именно месте вести бэклог — не так важно. Это может быть табличка в Экселе, в Джире, в Трелло, в Миро. Даже просто в офисе на стикерах — хотя этот вариант не самый удобный, стикер может оторваться и улететь куда-нибудь :)
Но! Важно, чтоб бэклог был в единственном экземпляре. Часть в Джире, часть в Экселе, а у команды разработки вообще какой-то свой — нет, так не пойдет. Бэклог должны видеть все, он должен быть максимально прозрачным.
То же касается и редактирования бэклога. Обычно этим занимается Продакт Оунер — но, в принципе, могут существовать некоторые внутренние договоренности о редактировании списка еще кем-то из команды. Например, дополнить задачку, декомпозировать ее, добавить данные после анализа может не только Продакт Оунер.
Бэклог — гибкий инструмент. И единственное требование к нему в этом смысле — актуальность. Если в бэклоге находится задачка трехгодичной давности, возникают вопросы.
Для работы с бэклогом существует отдельная встреча, которая называется Product Backlog Refinement, на которой команда вместе с Продакт Оунером разбирает и «чистит» бэклог: проверяет актуальность задач, декомпозирует уже существующие. Частота такой встречи — не больше 10% времени от спринта. То есть если спринт двухнедельный, то одна двухчасовая встреча.
Если команда находится в самом начале разработки продукта, процент таких встреч может быть чуть выше.
Но на самом деле эти правила не высечены в камне — просто Продакт Оунер и команда должны понимать, что работу с бэклогом нужно вести регулярно.
Собственно, я, как Agile-коуч, чаще всего сталкиваюсь с тем, что:
- Бэклогов несколько
- Там находятся древние неактуальные задачи
- Отсутствует прозрачная приоритизация задач
- Задача в бэклоге прописана так, что сама команда уже через неделю не понимает, о чем это и зачем
Подытожим:
- Бэклог должен быть один на всех
- Задачи в бэклоге должны быть актуальными
- Необходимо приоритизировать задачи, а крупные — декомпозировать
- Писать задачи понятным языком и при внесении в бэклог убедиться в понятности формулировок.