Just in time backlog population

В Харькове на втором тренинге нас долго мучили вопросами типа:
"Так кто же и когда уточняет и пережёвывает элементы беклога?".

Есть две стратегии:

Стратегия 1. Уточнять верхнюю часть беклога во время планирования очередного спринта.

Это работает. Но фаза планирования при этом может стать довольно болезненной и непредсказуемо растянутой. Причиной служит большое количество вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь между спринтами команда формально простаивает, а значит нужно как можно скорее запустить спринт).

В лучшем случае у заказчиков и команд хватает терпения доделать эту работу, правильно спланировав спринт.

В худшем же (к несчастью приходилось видеть такое на проектах) - планирование останавливается на фразе: "всё, пора. там посмотрим" и начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и членов команды друг другу), ни детального спринт беклога с оценками времени (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой ситуации не представляется возможным построить burndown, и таким образом теряется предсказуемость и адаптивность процесса.

Результат - естественно, куча недоделанных фич ибо не было чётко понятно попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и команды.

Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой проблемой довольно быстро и когда понимают, что книги не дают ответов, начинают искать ответы, применяя свой здравый смысл. Если конечно к этому моменту не утонут в незавершённых фичах и критике Скрама.

Стратегия 2. Распараллеливать разработку беклога и проработку его будущих частей.

Столкнувшись с проблемой, описанной выше, и уделив ей достаточной внимание, команды могут принять решение прорабатывать элементы беклога для следующего спринта до завершения предыдущего.

Это работает. только естественно, на это нужно выделить время в текущем спринте. Но это не так сложно - в спринт беклоге появляются задачи типа:

уточнить фичу А, потратив не более 4 часов, ответственный Миша

С первого взгляда этот подход ничем не отличается от первого. На самом же деле здесь у команды есть чёткий план борьбы с хаосом и неопределённостью. Плюс на выходе спринта всегда есть начальный план, сделанные задачи, не сделанные задачи и уточнённый беклог, готовый для планирования следующего спринта. Ни это ли что нам нужно?

Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу - задачу постепенного уточнения элементов беклога.

Обсуждение этой темы