​​Как мы готовим задачи к спринту

У нас болели груминги, но на самом деле болела неструктурированность подготовки задач.
Бывало, что всей толпой обсуждали совсем сырую задачу без критериев приемки. Буквально 10 человек смотрели, как один заводит задачу, и вместе рожали туда из головы критерии приемки.
В идеале фича-драйвер приносил на общую встречу уже первично описанную задачу с критериями и декомпозицией. Но это держалось на энтузиазме и проактивности фича-драйвера, и процесс подготовки задач отличался по каждому направлению.

Пришло время структурировать процесс.

Как писал в прошлом посте, начать стоит с вопроса: а что такое готовая к спринту задача? Собраться всей командой и набрейнштормить себе чеклист Definition of Ready for sprint.

Допустим, в DoR входят продуктовые критерии приемки, декомпозиция на подзадачи, контракты между бэком и фронтом и оценка.
Нужны ли все вместе на одной встрече, чтобы подготовить всё это?
Полагаю, что нет. Сначала есть асинхронная работа:
1. Продакт может подготовить критерии приемки сам и обсудить их с фича-драйвером.
2. Фича-драйвер может сделать первичную декомпозицию задачи и подготовить черновик контрактов.
Вот это можно уже приносить всей команде на доуточнение и оценку. Совместными усилиями можно нагенерить еще корнер-кейсов или придумать, как удешевить разработку в 10 раз.

Её мы обычно разбиваем на этапы. Простейший и самый распространенный вариант — To Do, In Progress, In Review, Done.
Подготовку задачи так же можно разбить на этапы и отразить этот процесс на канбан-доске.

Для своих команд я вижу такой идеальный процесс подготовки задач к спринту:
1️⃣ — Продуктовая проработка. На этом этапе продакт сам или вместе с фича-лидом описывает, зачем и что нужно сделать. На что это повлияет с точки зрения пользователя и бизнеса. Как продакт видит задачу завершенной — критерии приемки. Тесткейсы тоже могут появиться на этом этапе, с привлечением QA.
2️⃣ — Техническая проработка. На этом этапе фича-лид сам или с привлечением других экспертов описывают задачу технически. Если нужно, можно собрать брейншторм всей командой. Или взять ресерч в спринт.
3️⃣ — Оценка. Это тот самый этап, когда каждый член команды может оценить задачу, и оценки должны сойтись. Не принципиально, будут это майки или стори-поинты. Главное — это этап принятия командой задачи как готовой к спринту.
4️⃣ — Готово к спринту. Здесь самое время прокликать чеклист DoR и увидеть, не пропустили ли какой-то из этапов подготовки. Можно сказать, в момент перетаскивания задачи в эту колонку команда коммитится, что может сделать задачу за понятное время.

В общем случае, стоит доводить до конца уже начатую работу. Если есть задачи, готовые к оценке — в первую очередь оценить их.
Если таких задач нет, — возможно совместно декомпозировать, докидать технических деталей, или продуктовых критериев приемки. Но скорее всего, для этого собирать всю команду не нужно.

Мы пришли к тому, что встречу-PBR собираем в случаях, если нужен совместный брейншторм или уже можно оценить задачу. Но первично её уже кто-то должен был проработать.

В отдельном посте напишу подробнее, как инженеры прорабатывают задачи в спринте. В двух словах:
Чтобы проработка тоже считалась полноценной работой инженера, заводим таску-ресерч на фича-драйвера в спринт. В таске на ресерч тоже прописываем критерии приемки: на выходе с ресерча должны получить артефакт в виде схемы в миро и оцененные задачи.

На скрине наша канбан-доска, которая отражает процесс, описанный выше.
Если у вас болит проработка задач, советую описать ваш процесс, нарисовать свою доску и использовать её на PBR.
Это поможет описать процесс, структурировать его и возможно даже сразу улучшить.