Это перевод статьи Романа Пихлера "Когда должен состояться груминг бэклога?"
Разгрумленный бэклог продуктов облегчает разработку: в него попадают новые идеи и уточнения по задачам, а старые элементы постоянно актуализируются.
Но когда вы должны работать над уточнением бэклога? До начала нового спринта или после? И как решить, какой вариант подходит? В этой статье расскажем о четырёх вариантах с их преимуществами и недостатками, которые помогут сделать правильный выбор.
Вариант 1: на ревью спринта
Первый вариант — работать с бэклогом на ревью спринта. Предполагается, что:
- в процессе разработки был создан «готовый» инкремент продукта,
- присутствуют нужные люди,
- можно использовать обратную связь от участников.
Эти условия подходят для принятия решений по продукту и обновления бэклога, как предлагает Scrum Guide.
Этот подход гарантирует, что бэклог будет обновлен до начала следующего спринта. Это позволяет незамедлительно предпринять какие-либо действия, тем самым снижая риск уйти в неправильном направлении. Кроме того, работа над бэклогом ведётся совместно. Это повышает интерес людей, участвующих в событии по обзору спринта.
Но это работает только в том случае, если участники:
- могут предоставить соответствующую обратную связь,
- готовы сотрудничать,
- могут быстро согласовать необходимые изменения.
Более того, обратная связь не должна требовать дальнейшего анализа или вызывать большие изменения в бэклоге.
Этот метод не подходит, если у проекта много неопределённых задач и высокая степень неизвестности/вероятности изменений. Например, когда вы работаете над новым продуктом или продлеваете его жизненный цикл.
Вариант 2: отдельная сессия до планирования спринта
Второй вариант — провести отдельную встречу по бэклогу продукта до следующего планирования спринта. Сессия должна включать владельца продукта, команду разработчиков и Scrum-мастера. Совместно анализируя данные и работая над бэклогом, scrum-команда:
- снижает риск сделать неверные выводы из-за искажений восприятия,
- использует творческий потенциал и знания команды,
- повышает понимание и заинтересованность,
- приводит к лучшим требованиям.
П/п: встреча может занимать любой день в спринте. Роман предпочитает проводить сессию прямо в начале следующего спринта. Это нарушает правило Scrum, согласно которому собрание по планированию должно быть первым событием в каждом спринте. Но это «позволяет реагировать на обратную связь в последующем спринте, не спеша и не отодвигая ретроспективу спринта, не работая допоздна или в выходные дни».
Более того, это даёт отделить сбор данных от анализа: позволяет просматривать обратную связь без присутствия людей, которые её предоставили. В этом случае есть больше времени для оценки обратной связи, генерации правильных идей и принятия важных решений о продукте и соответствующем изменении бэклога. Это облегчает работу со сложными «хотелками», а также позволяет вносить большие изменения в портфель продуктов.
Обратите внимание, что этот подход предполагает, что вы можете получить обратную связь на ревью спринта, например, во время демонстрации продукта, теста на юзабилити или во время другого собрания.
Вариант 3. Отдельное собрание после планирования спринта
Если вы проверяете решения по продукту, выпуская программное обеспечение (выбранным) пользователям, тогда вам подойдёт третий вариант.
Предполагается, что вы проведёте встречу по бэклогу продукта с участием команды разработчиков и Scrum-мастера после планирования следующего спринта.
Этот подход предполагает, что вам потребуется несколько дней для сбора пользовательских данных, прежде чем вы сможете проанализировать их и внести соответствующие изменения в бэклог. Это также предполагает, что вам не нужно ждать новых данных, чтобы принять решение о цели этого спринта. Вы можете продолжить спринт и собирать данные для груминга.
У этого варианта тоже есть недостаток. Так как спринт защищён от изменений, самый ранний момент, когда можно отреагировать — это текущий спринт+2 (n+2). Поэтому рекомендуется начинать груминги с подхода 1 и 2, а переходить к варианту 3 после устранения критических рисков.
Кроме того, вы должны сосредоточиться на другой фиче в спринте n+1 по сравнению со спринтом n, чтобы избежать риска принять неправильные решения.
Вариант 4: постоянно
Если вам не нужно ждать окончания спринта, прежде чем выпускать новую или улучшенную функциональность, тогда подойдёт четвертый вариант:
— вы постоянно собираете данные, анализируете их и соответствующим образом изменяете бэклог.
Возможно, вы захотите отвести 30 минут каждое утро, чтобы посмотреть последние данные и сделать правильный вывод из них, желательно с помощью команды разработчиков или некоторых её членов.
Обратите внимание, что вариант 4 предполагает, что команда вносит постепенные улучшения в продукт или проводит несколько параллельных экспериментов, чтобы проверить идеи для новых фич.
Строго говоря, Scrum плохо подходит для поддержки такого подхода. Спринт предназначен для запуска одного эксперимента или реализации фичи соответствующего продукта (акцент на 1-2 крупных задачах). Спринт не особенно подходит для выполнения нескольких тестов, постоянного выпуска небольших улучшений и исправления ошибок. Поэтому вы можете подумать о переходе от Scrum к процессу, основанному на Канбан.
В нашей компании команды обычно договариваются использовать вариант 3, но иногда есть периоды, когда груминг идёт постоянно. А какое место занимает груминг в вашей команде?