Discovery Kanban 🌌 — применение Kanban для работы с большим бэклогом и его приоритизации.

Это применение Kanban подхода для работы с элементами бэклога (User Story и другие задачи).

Для работы с большим бэклогом и его приоритизации. Работа по Discovery Kanban позволяет сфокусироваться владельцу продукта на самом важном и ценном.

Начните с создания канбан доски с четыремя столбцами: запросы, User Story, декомпозиция, бизнес ценность. Занесите все ваши запросы и User Story в этот бэклог, сделайте декомпозицию и выделите бизнес ценность каждого запроса. Оставляйте и берите в работу только те задачи, которые дойдут до конца доски.

Давайте разберем более подробно, зачем нужен Discovery Kanban.

Предположим, что вы — владелец продукта или менеджер проекта, и вам нужно давать задачи в работу команде разработки.

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

Одна из лучших практик здесь — груминг бэклога. Удаляем то, что устарело, добавляем то, что нужно добавить. Проверяем, насколько элементы бэклога соответствуют целям компании. Если задачи неопределенные или содержат много элементов, используем User Story Mapping — этот метод позволяет разбить огромную функцию на части, как бы сделать декомпозицию.

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

Здесь на помощь приходит Discovery Kanban.

Discovery Kanban отличается от «обычного» Delivery Kanban.

В обычном Kanban ваша цель — визуализировать работу, сделать её прозрачной, ограничить количество WIP (Work In Progress, Работы в процессе), и управлять потоком работы.

Discovery Kanban подходит скорее для бэклога, чем для самой работы, потому что он визуализирует решения и возможности, и управление здесь идет именно этим потоком решений и возможностей.

При этом на каждом этапе процесса Discovery Kanban часть возможностей может «отвалиться». Это значит, что эта возможность не пойдет в работу к команде разработки, и это значит, что мы не потеряем деньги, занимаясь тем, чем не нужно.

Для начала проектируем Канбан доску. Размечаем столбцы:

• Запросы (Reqests) — это идеи для бизнеса
• Пользовательский истории (User Story)
• Декомпозиция
• Бизнес ценность

Далее, начинаем работать с бэклогом.

• Формулируем User Story по классическому шаблону — Я как (роль) хочу (фича) потому что (цель).
• Декомпозируем на элементы, если необходимо. Следите при этом, чтобы каждый элемент сохранял хотя бы минимальную бизнес ценность.
• Определяем бизнес ценность вместе с Product Owner или менеджером проекта / продукта.

Весь процесс в этой системе — это «поток возможностей». На любом этапе мы можем отказаться от любого элемента бэклога, если это оправдано, если мы принимаем решения. Ведь одно из главных слов, которым должен владеть Product Owner — это «нет».

Discovery Kanban выступает как своего рода фильтр, через который мы пропускаем элементы бэклога для команды разработки.

Это упрощает работу, делает её более предсказуемой. Команда всегда занята, и всегда делает вещи первостепенной важности, даже бэклог предстоит разбирать еще месяц и туда постоянно валятся новые задачи.

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

WIP лимиты помогут системе оставаться неперегруженной.

Этот лимит лучше делать в Story Points, а также делать его диапазонным — от какого–то значения до какого–то.

WIP лимиты нужны, потому что ваша канбан система должна быть наполненной, чтобы команда не простаивала, а всегда что–то делала.

Story Points нужны, чтобы установить диапазон таким образом, чтобы команда не могла взять больше, чем может, ведь вы установите лимиты таким образом, чтобы они были немного больше обычной velocity команды. Тогда команда всегда будет в работе, а поток будет двигаться быстро, потому что система не будет перегружена.

Также лучше установить формальные правила перехода User Story из одного этапа в другой. Так в процессе работы с доской вам будет проще принимать решения, перетягивать задачу на новый этап или нет, и если нет — то что нужно, чтобы дело пошло.

Обеспечивать поток Discovery Kanban может любой менеджер. Главное, чтобы он обладал соответствующими компетенциями, и лучше всего, если этот человек сфокусирован на оптимизации процессов.

Например, это могут быть:

• Service Request Manager, если у вас Канбан.
• Scrum Master, если у вас Скрам — потому что он хороший фасилитатор, он отвечает за процесс, и у него это лучше всего получится. Product Owner — отвечает за ценность, а не за скорость, поэтому в его реализации поток может быть медленнее.

Главное, что этот человек должен отслеживать, нужно ли на самом деле делать фичу. Если с доской работает Scrum Master, он может уточнять этот вопрос у Product Owner.

Если нужно — то выяснять, что нужно для того, чтобы перетащить её на следующий этап.

Также он проверяет установленные правила, чтобы они соответствовали целям работы.

• Запросы (Reqests) — это идеи для бизнеса
• Пользовательский истории (User Story)
• Декомпозиция
• Бизнес ценность