Привет! Сегодня расскажу про чек-лист, какие процессы нужно выстроить для новой Дискавери-команды.

Дискавери-команда занимается обоснованием и проработкой инициатив, которые затем попадают в продуктовый бэклог для последующей реализации в Деливери.

Дискавери в первую очередь отвечает на вопросы «Что делать?» и «Надо ли вообще делать?». Деливери - «Как делать?».

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

Для запуска с нуля команды Дискавери и их процессов мы используем следующий чек-лист:

В команде нужно выделить Дискавери-мастера (им может быть Продакт, Аналитики или Дизайнер), он должен прочитать Scrum Guide, посмотреть видео про Agile, Delivery, пройти базовое обучение по Agile и Scrum, специализированный курс для Скрам‑Мастеров и сдать тест на 85%+
Команда должна вести дискавери-бэклог проблем и решений и бэклог дискавери-спринта в JIRA;
Работу над обоснованием и проработкой инициатив организовать спринтами (1-2 недели);
Команда-дискавери должна тратить минимум 30% времени спринта на уточнение гипотезы о проблеме и решении;
Планирование Спринта и груминг бэклога (PBR - Product Backlog Refinement — это уточнение элементов бэклога продукта) проводить каждый спринт. На PBR выделяется 2 часа за 2-х недельный спринт и на этой же встрече оцениваются задачи, при этом длительность и количество PBR-ов может уменьшаться или увеличиваться в зависимости от того, достаточно ли в бэклоге продукта задач для следующего дискавери-спринта;
В самом начале планирования определять цели спринта. Сначала в бэклог спринта набираются задачи влияющие на цель спринта, потом все остальное. Команда не берет в спринт задач больше, чем ее средняя Velocity (скорость команды,объём работы) - т.е. больше, чем они обычно делают. Возможен другой вариант, что цель спринта формулируется в конце планирования, как логическая связка набранных в спринт элементов бэклога. Цель может быть кроссфункциональной, например, «сделать решение для онбординга байеров и каждый в команде свою часть решения делает. Цель можно заводить и брать в спринт как задачку в JIRA с определенным типом, например, "Goal";
Дейли в команде проводить регулярно (ежедневно либо несколько раз в неделю), в одно и тоже время. На этой встрече команда всегда фокусируется на целях спринта, проговаривает проблемы, мешающие или замедляющие достижение целей спринта;
Проводить встречу Демо (обзор спринта) каждый спринт, в результате этой встречи должна быть обратная связь от ключевых стейкхолдеров. Из рассказа команды на Демо должно быть понятно каким образом цели спринта связаны и сдвинули дискавери ОКРы на квартал;
Встречу Ретроспективу проводить раз в спринт. При необходимости, после каждого ретро формулируются и заносятся сформулированные действия по решению проблем (Retro Action Items). Проблемы, которые не могут быть решены на уровне команды и тимлида, эскалируются на уровень выше (на уровень Юнит Лидa или Кластер Лида). На каждом ретро команда анализирует статус выполнения таких задач с прошлых ретро;
У команды должен быть бэклог улучшений (action items) с ретроспектив в JIRA (с отдельным типом задачи), такие задачи также берутся в бэклог спринта;
У команды в Confluence должны быть описаны и соблюдаться критерии взятия задачи в спринт DoR (Definition of Ready — это набор критериев, которые определяют, когда задача готова к началу выполнения);
Необходимо описать и строго соблюдать DoD (Definition of Done - критерии качества проработки инициатив) на выходе из дискавери-спринта. DoD дискавери команды при этом должен быть синхронизирован с Definition of Ready (DoR) в деливери команде или командах, куда поставляются проработанные инициативы;
В каждой задаче в JIRA должны быть прописаны специфичные для нее Критерии Приемки (Acceptance Criteria) или образ результата;
В дискавери-бэклоге команда каждую задачу должна ранжировать - повысить или понизить приоритет задачи в списке (используя скоринговую модель, например RICE);
У команды должен быть дискавери-роадмап на 2 спринта вперед, тк дискавери должно опережать деливери минимум на 2 спринта, и не создавать для деливери команды дефицит обоснованных инициатив, которые можно взять в работу;
Команда должна знать и уметь пользоваться всеми каналами своих пользователей (support, sales, отзывы из сторов, UX, Маркетинг итд);
У команды должно быть единое место cбора и хранения гипотез, проблем, пожеланий клиентов, приходящих из разных каналов, чтобы связывать или отмечать инсайты, которые пришли из разных каналов;
Команда должна ориентироваться на ценности продукта для клиентов на основе регулярного сбора и анализа обратной связи (Voice of Customer) до и после запуска продукта;
В спринте должна быть роль, которая отвечает за разбор Voice of Customer, при этом «шапка» может переходить между участниками из спринта в спринт.

__________________________________________________________________

Discovery Sprints

Дискавери-спринты идут параллельно со спринтами разработки и нужны для того, чтобы получать проработанные обоснованные инициативы в продуктовом бэклоге. По сути, это — тот же скрам с такими же событиями внутри. Дискавери-спринты не тормозят выпуск инкрементов, они идут параллельно опережая спринты разработки не менее чем на 2 цикла вперёд. Хороший бенчмарк, когда задачи для команд проработаны на 2 спринта вперёд. В основе используется классическая методология дизайн-мышление (Design Thinking): от симптома к спектру проблем, от них к спектру решений.

Какие проблемы решают отдельные дискавери-спринты

В скрам-гайде не написано, как именно проработанные задачи попадают в продуктовый бэклог. Именно эту задачу решают дискавери-спринты;
Мало того, чтобы проработанные задачи попадали в бэклог. Важно, чтобы в бэклог попадали обоснованные инициативы;
Мы привлекаем и вовлекаем разработчиков на ранних стадиях, снижая риски того, что задачи будут недостаточно проработаны;
В спринтах разработки дизайнер, аналитик и продакт участвуют эпизодически, т.к. они напрямую не влияют на инкремент. Теперь они участвуют в диско-спринтах на 100%.
При выборе решений и проблем начинают системно рассматриваться альтернативы, а не берётся первое попавшееся решение.
Бэклог пополняется систематически и регулярно самыми важными вещами, а не тем чем придётся.
Продакты не закапываются в детали, а системно работают над дискавери задачами. Метрикой успеха является количество обоснованных инициатив за спринт.
Между продактами, дизайнерами и аналитиками создается «кросс-опыление» и они начинают «T-шейпиться» (делиться экспертизой, выполнять разные роли).
В ситуации, когда юнит неполностью укомплектован аналитиками, дизайнерами и продактами не нужно делать ресурсное планирование «стаканами», а все решается в едином спринте.

Какие могут быть проблемы

Разработчики, так как они не в диско-командах, не принимают участие в проработке задач. Но при необходимости мы можем заранее договориться и запланировать его привлечение к диско-команде;
При отсутствии прозрачности между спринтами и командами диско и деливери - проводим последовательные встречи: деливери-демо, а потом диско-демо; сначала деливери-стендап, а потом диско-стендап.
Если разработка ждет пока дискавери подготовит задачи, то нужно диско-команде идти с опережением в 1-2 спринта;
Бывают случаи, что у продактов разные цели и они не помогают друг другу в их достижении, тогда необходимо ставить общие цели/OKR на весь диско-стрим;
Когда много дополнительных встреч, то следует принимать их только, если видите от этого ценность.

Роли

Disco Master — это не человек, который заводит таймер и не секретарь для команды, а лидер команды. Он коучит и улучшает команду, заинтересован в том, чтобы проводились ретроспективы, команда училась и процесс прокачивался. Это драйвер изменений, который улучшает сам процесс.
Disco Team — Продакт, Аналитик, Дизайнер, UX-исследователь, Разработчики, TUL

События

Disco Scrum — одно или двухнедельный спринт, результат которого получить не менее одной обоснованной инициативы;
Disco Planning — определить цели спринта, оценить и декомпозировать задачи;
Disco Daily — убедиться, что прогресс по целям «в работе»;
Disco Retro — понять, что было хорошо и что можно сделать лучше, не менее одного улучшения взять в следующий спринт;
Disco Sprint Review — получить фидбэк (обратную связь) команды разработки и стейкхолдеров по обоснованным инициативам;
Disco Grooming — понять, что мы хотим из беклога взять в следующие спринты и проработать + привлечь команду разработки на ранних стадиях

Discovery Definition of Done

На выходе диско-спринта мы получаем либо описание проблемы (которая будет анализироваться в будущих диско-спринтах), либо решения (которое потом пойдет в деливери). Поэтому Definition of Done состоит из 2-х частей (проблемы и решения).

Пример для описания проблемы (Definition of Done для проблемы):

1. Какую проблему решаем?
2. В чем причина проблемы?
3. Откуда мы про нее знаем?
4. Кто сталкивается с этой проблемой? Сколько их?
5. Насколько для них эта проблема критична?
6. Как мы оценим успех? Как мы заработаем на этом?
7. Кто из других юнитов связан с этой проблемой? Кого это может коснуться?

Пример для описания решения (Definition of Done для решения):

Какое решение можно предложить, не тратя наших ресурсов?
Какие решения для аналогичной проблемы предлагают конкуренты?
Почему предлагаемое нами решение лучше для компании и для пользователя, чем п1 и п2?
Как протестировать, что наше решение работает?
Что является хорошим и плохим результатом теста?
Как решение встраивается в CJM всего продукта? Откуда начинается сценарий?
Это финальная версия? Как мы видим решение в целевом варианте?
Как информировать пользователей об изменениях? Откуда они узнают про решение?

При этом Definition of Done команды дискавери для решения должен стыковаться с Definition of Ready для деливери-команды

Полезные ссылки

Выстраиваем процессы в Discovery-команде