WSJF или приоритезация, когда все вокруг — «сложно»

На днях вел сессию приоритезации задач в одном крупном украинском банке. История стара как мир: есть много эпиков, и все «очень важны для нас». Наверное, вы тоже не раз были в такой ситуации, когда сложно объяснить стейкхолдерам, почему нулевой приоритет у 10 задач — не работает.

В этой небольшой заметке расскажу вам, как эту проблему обычно решаю я. Представьте себе очень большую компанию, где неведомое количество стейкхолдеров на один ваш небольшой, но гордый, проект. Допустим, у вас есть 10 фич разной величины и сложности, которые для вашего Product Owner — «все одинаково важны». Давайте поможем ему (или ей) в этом немного разобраться.

Приоритезация. Теория

Мы с вами знаем, что очень плохо иметь 10 «самых приоритетных задач» (это вызывает переключение, пожаротушение, крик “нужно прямо сейчас” и тд). Наша с вами задача — помочь владельцу продукта ОБЪЕКТИВНО выбрать ту одну, над которой наша команда будет трудиться следующей. Для этого я использую WSJF из Scaled Agile Framework (оставим за рамками этой статьи холивар LeSS vs. SAFe).

Что такое WSJF — Weighted Shortest Job First: это многокомпонентная система оценки, на выходе с которой вы получаете приоритезированный список задач, где первая — самая простая в реализации, но при этом и самая ценная с точки зрения бизнеса. Формула проста:

Где Cost of Delay:

Давайте более детально:

Бизнес (или клиентская) ценность — на сколько эта инициатива принесет пользу для бизнеса или клиента.

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

Фактор риска (или возможности) — на сколько эта инициатива уменьшает риск или открывает новые возможности. Например, выполнив эту задачу мы сможем выполнить следующие 10, или эта задача пришла от государственного регулятора.

Сложность работы — на сколько технически сложно реализовать эту инициативу.

И так, самое интересное! Первые три параметра, по отношению к каждому элементу, оценивает бизнес, а последний — ИТ. Но как оценивают?

Оценивание

Оценивание выполняют, используя ряд Фибоначчи, то есть в Story Points (далее просто поинты). Он очень удобен для этого, так как шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 поинта и 21.

Итак, нашу группу мы разбиваем на 2 лагеря: бизнес и ИТ. Садим за разные столы, даем в руки Planning Poker карты (или делаем их со стикеров, или используем телефон). Если необходимо, проводим небольшое обучение магии голосования. Скажу честно, можно обойтись и без карт, иногда это быстрее. Так что выбор за вами.

К этому моменту у вас должна быть подготовленная физическая доска. Да, именно физическая, не Jira, и не Version One. Физическая визуализация поможет всем говорить об одной картине на одном языке. Как только вы делаете это онлайн, все видят разное. На доске вертикально — ваши эпики/стори/инициативы, горизонтально — наименование факторов оценки.

Должно выйти что-то такое:

Дальше даем время и просим их оценить каждую задачу в каждой колонке в Story Points по отношению друг к другу. Здесь важно объяснить, что они берут колонку-за-колонкой. То есть, например, выбирают первую колонку Business Value расставляют оценки ко всем задачам в ней, только потом переходят к следующей. Это важно, потому что держит общение в рамках одного параметра.

По мере выполнения задачи просим их выносить оценки на доску.

Итог

В скором времени доска примет вот такой вид:

В моем случае я добавил еще один параметр оценивания для ИТ — Зависимости. Таким образом я хотел визуализировать, как некоторые, с виду простые, задачи, на самом деле очень сложны к выполнению из-за обилия вендоров.

Далее, дело за малым — суммируем и считаем баллы.

Победил тот, у кого выше балл :)

Что делать, если спорят?

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

В случае сильного сопротивления нужно идти вглубь, то есть погружаюсь в задачу, которую бизнес выбрал, вместе с ними, чтобы расширить контекст. Для этого я использую Impact Mapping. Но об этом уже в следующей статье!