Agile-фреймворк WSJF

Weighted Shortest Job First (WSJF) помогает расставлять приоритеты работ, балансируя между стоимостью задержки и размером задачи. Этот фреймворк позволяет получать максимальную ценность при ограниченных ресурсах в быстро меняющихся условиях.

О приоритизации WSJF в двух словах

Создайте бесплатный аккаунт Prioplan

Расчёт WSJF

Оценка WSJF = (Бизнес-ценность + Критичность по времени + Снижение рисков) / Размер задачи

Критерии

Пользовательская/бизнес-ценность ранжирует задачи по их важности для пользователей и потенциальному влиянию на доход.

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

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

Продолжительность задачи (также называемая story points, feature points, трудозатраты или относительный размер) измеряет сложность реализации. При такой оценке меньшие числа лучше.

Оценка

1. Оценивайте каждый критерий по шкале Фибоначчи: 1 (нет влияния), 2, 3, 5, 8, 13, 21 (максимальное влияние).

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

3. Оценивайте задачи перед каждым событием планирования итерации (спринта).

4. Нормализуйте разные оценки через обсуждение с коллегами.

5. Разделяйте инициативы с размерами задачи '21' и '13' на меньшие проекты (уточнение бэклога).

6. Сбрасывайте оценки каждые пять итераций (Program Increment), чтобы отразить быстро меняющиеся условия.

Примените готовый шаблон приоритизации Prioplan

Не нужно настраивать критерии, формулы и шкалы. Используйте их как основу для начала встречи.

Примечание

WSJF — это не просто формула, а часть обширного фреймворка рабочих процессов для предприятий. Волшебство происходит, когда вы меняете подход к принятию решений: проводите совместные сессии приоритизации, устанавливаете протухание приоритетов, уточняете критерии и объясняете описания задач коллегам. Эта статья предоставляет инструменты для создания такой привычки приоритизации и изменения мышления.

Определение WSJF

WSJF означает Weighted Shortest Job First — фреймворк приоритизации для расстановки приоритетов в бэклогах путём расчёта относительной стоимости задержки (CoD) и размера задачи (аппроксимация продолжительности). CoD рассчитывается как сумма: Пользовательская/бизнес-ценность + Снижение рисков и создание возможностей + Критичность по времени. Это часть методологии SAFe.

Приоритеты бэклога постоянно обновляются на основе оценок приоритета WSJF. Фреймворк удобно и автоматически игнорирует невозвратные затраты — фундаментальный принцип экономики Lean.

В системе, основанной на потоке, непрерывная приоритизация задач для обновления приоритетов обеспечивает наилучшие экономические результаты для:

• Упорядочивания задач путём продвижения быстрых побед вперёд
• Баланса наивысшего финансового результата при снижении вложенных ресурсов
• Регулярного обновления CoD и размеров задач для отражения быстро меняющихся условий

Что такое SAFe?

Scaled Agile Framework (SAFe), согласно ScaledAgile.com, — это система для внедрения практик Agile, Lean и DevOps в масштабе. Она берёт лучшие идеи из гибкой поставки продуктов и расширяет их на всё предприятие для обеспечения бизнес-гибкости. SAFe — самый популярный фреймворк для ведущих предприятий, потому что он работает: ему доверяют, его можно настроить, и он устойчив.

Он постоянно обновляется и имеет версии. В 2022 году последняя версия — 5.1, и SAFe охватывает семь основных областей предприятия:

• Командная и техническая гибкость (Team and Technical Agility)
• Гибкая поставка продуктов (Agile Product Delivery)
• Поставка корпоративных решений (Enterprise Solution Delivery)
• Lean-управление портфелем (Lean Portfolio Management)
• Организационная гибкость (Organization Agility)
• Культура непрерывного обучения (Continuous Learning Culture)
• Lean-Agile лидерство (Lean-Agile Leadership)

Обещанные результаты:

• +50% сокращение времени выхода на рынок
• +50% снижение дефектов
• +35% увеличение продуктивности
• +30% более счастливые и вовлечённые сотрудники

В этой статье мы сосредоточимся на основе — фреймворке принятия решений WSJF.

Скачайте бесплатный шаблон WSJF:

Как рассчитать WSJF

Формула WSJF

Фреймворк Weighted Shortest Job First (WSJF) помогает решить, какую задачу выбрать следующей для поставки максимальной ценности при ограниченных ресурсах, находя баланс между стоимостью задержки (CoD) и размером задачи в быстро меняющемся мире.

Рассчитайте оценку WSJF

Оценка WSJF = Стоимость задержки / Размер задачи

Рассчитайте CoD, который определяет три типа проблем разработки продукта, за которыми вы должны следить.

Стоимость задержки = Пользовательская/бизнес-ценность + Критичность по времени + Снижение рисков | Ценность создания возможностей

Оценивайте каждый критерий по шкале 1, 2, 3, 5, 8, 13, 21.

Принципы оценки:

• Оценка WSJF направлена на понимание уровня неопределённости, а не на расчёт часов или денег (что практически невозможно). Поэтому мы оцениваем вероятность, а не точное время выполнения конкретной задачи. Это называется относительной оценкой.

• Поскольку основная цель — поставлять ценность на каждой итерации, медианой последовательности будет «одна итерация».

• Одна итерация = две недели. Наша базовая линия планирования. Мы рассчитываем числа story points для двухнедельной итерации.

• Program Increment (PI) = пять итераций (десять недель). Согласно SAFe, PI — это временной период, в течение которого Agile Release Train (ART) поставляет инкрементную ценность в виде работающего, протестированного ПО и систем. Вся команда реализует что-то крупное для продукта. Другими словами, организация выпускает крупное обновление, после которого они должны переоценить свой бэклог, подумать и снова обсудить приоритеты.

Настройка

Это только рекомендация, и вы можете настроить подход любым удобным для вашей команды способом. Позже в этой статье мы рассмотрим, как лучше понять и настроить критерии именно для ваших бизнес-потребностей.

Пользовательская/бизнес-ценность (UBV)

Новые функции и инновации, которые продвигают ваш продукт вперёд. Например, корпоративные опции безопасного входа помогают избежать жалоб от крупных клиентов, что ведёт к продажам.

Пользовательская/бизнес-ценность (UBV) ранжирует ваши задачи по их относительной важности для пользователя (приоритизация желательности) и потенциальному влиянию на доход (финансовая приоритизация). На этом этапе вы оцениваете, насколько эффективно это решение продвигает вашу ключевую метрику. Поскольку многие факторы могут влиять на UBV, начните думать о бизнес-влиянии и повышайте уверенность, что всё сработает.

Вопросы для ответа: Какую важную метрику продукта вы можете обновить? Насколько это важно для пользователей? Каково влияние на доход?

Оценка пользовательской/бизнес-ценности по последовательности Фибоначчи

• 1 балл: нет пользовательской/бизнес-ценности вообще; эта задача связана с чем-то другим
• 2 балла: минимальное бизнес-влияние и уверенность
• 3 балла: низкое бизнес-влияние и уверенность
• 5 баллов: умеренное бизнес-влияние, умеренная уверенность
• 8 баллов: высокое бизнес-влияние и уверенность
• 13 баллов: очень высокое бизнес-влияние и уверенность
• 21 балл: максимальное бизнес-влияние и уверенность

Критичность по времени (TC)

Оценивайте срочность. Инициативы имеют обоснованные дедлайны, такие как новые регуляции, налоговая отчётность, сезонные акции и т.д.

Критичность по времени ранжирует задачи по срочности. Вы оцениваете, как ценность будет снижаться со временем или сколько клиентов вы можете потерять, если будете медлить.

Наш временной период оценки — от одной итерации (две недели) до одного Program Increment (PI) (десять недель). На каждом цикле PI мы проводим новую сессию переоценки (после протухания приоритетов) и решаем, как изменилась срочность.

Вопросы для ответа: Насколько это срочно для бизнеса? Будут ли пользователи ждать или перейдут к другому решению? Есть ли фиксированный дедлайн?

Оценка временной критичности по последовательности Фибоначчи

• 1 балл: совсем не критичная по времени задача
• 2 балла: может подождать до следующего цикла оценки (после протухания приоритетов каждые пять итераций)
• 3 балла: может подождать четыре спринта (около восьми недель)
• 5 баллов: умеренная срочность, может подождать три спринта (около шести недель)
• 8 баллов: может подождать два спринта (около четырёх недель)
• 13 баллов: может подождать один спринт (около двух недель)
• 21 балл: максимальная срочность, вы должны взять эту задачу в следующий спринт

Снижение рисков | Ценность создания возможностей (RR | OE)

Задачи для избежания или снижения технологических или бизнес-рисков. Примеры включают рефакторинг кода, обновление базы данных, безопасность или налоговый аудит — что-то, что вы должны сделать для обеспечения здорового функционирования продукта.

Снижение рисков и создание возможностей помогает выделить задачи, которые могут не приносить доход немедленно, но приносят пользу в долгосрочной перспективе. Некоторые решения устраняют технические или юридические риски и экономят вам деньги позже. Другие могут открыть двери для дальнейших улучшений, которые значительно увеличат количество потенциальных клиентов.

Вопросы для ответа: Если задача начинается с описания какого-то риска, насколько большое влияние будет у этого риска? Какова вероятность?

Оценка снижения рисков по последовательности Фибоначчи

• 1 балл: не обеспечивает никакого снижения рисков вообще
• 2 балла: снижает вероятность минимального риска, минимальная вероятность серьёзности
• 3 балла: снижает вероятность низкого риска, низкая вероятность серьёзности
• 5 баллов: снижает вероятность умеренного риска, умеренная вероятность серьёзности
• 8 баллов: снижает вероятность умеренно-высокого риска, высокая вероятность серьёзности
• 13 баллов: снижает вероятность очень высокого риска, очень высокая вероятность серьёзности
• 21 балл: может снизить риск сильно влияющего события, катастрофы, которая, скорее всего, произойдёт

Размер задачи (продолжительность задачи)

Размер задачи — единственный негативный фактор, который ранжирует задачи по сложности реализации. Невозможно достичь максимальной окупаемости инвестиций без учёта стоимости человеко-часов. Продолжительность также называется story points, feature points, трудозатраты или относительный размер.

Вопросы для ответа: Сколько времени займёт реализация? Есть ли зависимости, которые могут сделать это более трудоёмким?

Оценка размера задачи по последовательности Фибоначчи (story points)

• 1 балл: не требуется никаких трудозатрат вообще. Мы не можем делить на ноль, поэтому наша оценка размера задачи должна начинаться с 1.
• 2 балла: базовая линия оценки. 80% вероятность, что одного дня достаточно для кодирования и одного дня для тестирования и валидации для двухнедельной итерации.
• 3 балла: задача примерно на четверть усилий вашего спринта
• 5 баллов: что-то на половину вашей итерации. 80% вероятность, что задача займёт 5 рабочих дней для кодирования и один день для тестирования и валидации для двухнедельной итерации.
• 8 баллов: 80% вероятность, что задача будет разработана и протестирована в течение двух недель (одна итерация/спринт)
• 13 баллов: между одной и двумя итерациями
• 21 балл: «оценки Базза Лайтера», что-то, что занимает два спринта или даже больше («до бесконечности и дальше»). По моему практическому опыту работы с командами, вы будете оценивать множество идей, которые превышают одну итерацию и должны быть разделены на меньшие части.

Финальная формула для расчёта оценки WSJF:

Оценка WSJF = (Бизнес-ценность + Критичность по времени + Снижение рисков | Создание возможностей) / Размер задачи

Настройте критерии для вашей команды

В стандартном фреймворке Scrum оценка story points каждой команды — и результирующая скорость — это локальная и независимая задача. Вот отправная точка для вашего процесса оценки. Вы можете применить её из шаблона WSJF Prioplan и изменить описания критериев.

Не существует единственно правильного определения для шкалы. Если вы и ваша команда не понимаете какой-либо термин — меняйте его! Prioplan довольно гибкий в этом отношении.

Итерации

Ядро agile-процессов — это базовые строительные блоки, называемые итерациями или спринтами. Каждая итерация — это стандартный временной период фиксированной длины, в котором Agile-команды поставляют инкрементную ценность.

Событие планирования итерации (Product Increment)

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

Prioplan может сэкономить всю эту неделю для вашей команды через асинхронный процесс оценки. Установите день планирования, и Prioplan сделает всё остальное. Вы можете отслеживать прогресс оценки с помощью отчёта о прогрессе оценки команды.

Чтобы мотивировать коллег оценивать вовремя, предлагайте поддержку с ободряющими сообщениями. Перейдите в настройки привычки приоритизации и установите вознаграждающее сообщение для коллег, которые завершают оценку вовремя перед предстоящей встречей планирования итерации.

Сила переоценки

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

Вся идея SAFe — адаптироваться по-новому к быстро меняющемуся миру. Окружение компании меняется каждые пять итераций (один PI). Поэтому крайне рекомендуется сбрасывать оценки.

В системе, основанной на потоке, непрерывное обновление приоритетов обеспечивает наилучшие экономические результаты. Упорядочивание задач, а не теоретическая индивидуальная окупаемость инвестиций задачи, даёт лучший результат в таком контексте потока.

Побочная выгода переоценки бэклога — это уточнение бэклога. Думая о каждом элементе бэклога, вы получите идеи о том, как объединить, обновить или удалить задачу, поскольку некоторая информация устареет по какой-то причине. По опыту prioplan.app, мы удаляем от 2% до 5% элементов бэклога каждый цикл переоценки.

Чтобы настроить циклы переоценки:

1. Нажмите на Meeting in # days (Встреча через # дней).
2. Прокрутите вниз до раздела протухания приоритетов.

По умолчанию оценки вашей команды протухнут после начала следующего цикла PI.

По умолчанию спринт длится две недели. Настройте это в разделе привычек приоритизации.

Совет

Если ваши оценки протухли и вы не завершили предыдущий PI, вы всегда можете восстановить оценки и продлить период приоритизации.

Совместная приоритизация

Agile-оценка — это командный спорт. Каждая agile-команда состоит из пяти — одиннадцати членов. Пригласите вашу agile-команду (кросс-функциональную команду) в процесс приоритизации.

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

Вот почему вся agile-команда оценивает каждый элемент бэклога продукта.

Снижайте предвзятость

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

Иногда встречи по приоритизации могут проходить под руководством самого громкого человека в комнате. Это означает, что вы можете мешать друг другу во время сессии оценки. Позвольте каждому расставлять приоритеты в своём темпе.

Выбирайте «правильное влияние»

Мы говорили о бизнес-влиянии в начале статьи. Но какие ответы вы получите, если спросите разные роли простой вопрос «Что самое важное, что мы должны сделать дальше?» Например, я уверен, что разработчик скажет вам «более быстрая база данных», продавец скажет «запрос функции для крупнейшего клиента», а менеджер продукта спросит «новое сообщение об удержании» и т.д.

Практически невозможно сравнить, что более важно. Однако это хорошо учитывать для каждой agile-команды, и именно это Prioplan может сделать для вас.

Собирайте разные мнения

Фреймворки приоритизации отлично подходят для того, чтобы держать эмоции и политику вне решения, чтобы вы могли опираться на факты. Однако когда вы расставляете приоритеты в одиночку, вы всё ещё предвзяты. Позаимствуйте технику покерного планирования для приоритизации. С Prioplan пригласите каждого члена команды к приоритизации.

Чтобы пригласить коллег:

1. Откройте настройки критериев.
2. Пригласите коллег в вашу общую команду оценки.

Это предоставляет каждому коллеге свой список оценки для независимой оценки.

Уточните критерии для каждой роли

Допустим, вам нужно разработать новую функцию для вашего сайта. У вас есть как минимум три роли — UX-дизайнер, фронтенд и бэкенд — у всех разный размер задачи для этой функции. UX нужен размер задачи 3 дня, фронтенду нужен один день, а бэкенду нужно пять дней. Каков размер задачи для всего проекта?

Проблема не в вычислении; ваша команда должна найти временной интервал для обсуждения этого. В мире с удалённой работой это означает ещё один звонок в Zoom и обсуждение. Больше работы вокруг работы.

Prioplan может справиться с этим для вас с помощью асинхронного подхода к приоритизации.

Чтобы назначить критерии по роли:

1. Откройте настройки критериев.

2. Назначьте каждому пользователю критерий для оценки в соответствии с их экспертизой.

   

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

Когда все участвуют, это увеличивает вовлечённость

Побочный эффект совместной приоритизации в том, что коллеги лучше понимают, что происходит с продуктом. Мы знаем, какие у нас вызовы, запросы и идеи, и почему одни важнее других. Это повышает моральный дух и вовлечённость команды.

Нормализуйте оценки

Немного нормализации происходит через регулярную практику, помогая убедиться, что все в команде делают одинаковые предположения при оценке размера. Например, если один человек оценивает элемент в «2», но другой человек оценивает его в «8», учитывая, что они обладают схожими способностями, они по-разному интерпретировали требование или подошли к нему с разных направлений. Когда это происходит, разработчики сотрудничают с владельцем продукта, чтобы прояснить предположения и согласовать размер. (Это не обязательно должен быть консенсус — люди могут согласиться не соглашаться.)

Пока команда учится, что означает для них шкала Фибоначчи с их уникальным набором навыков, стажем и знанием домена, полезно сравнивать новые запросы с завершённой работой со схожими характеристиками. Например, когда новому элементу присваивается значение story point 5, сравните его с похожими вещами того же размера и соответствующим образом скорректируйте баллы.

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

Разделите на меньшие части

Одно из самых больших недопониманий о WSJF в том, что он может сфокусировать вашу команду только на лёгких задачах (низко висящих фруктах). Вместо этого, чем меньше размер задачи для конкретной задачи, тем выше оценка приоритета и тем выше будет ранжирована задача.

Используйте матрицу для разделения вашего бэклога на части и решите, что делать с вашими задачами.

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

Практические советы

• Не пытайтесь быть слишком точными. Если у вас есть задача на один час, не бойтесь установить базовую линию в один день. Всё это будет компенсировано и сбалансировано в долгосрочной перспективе.

• Округляйте оценки до следующего значения.

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

Связанные ресурсы

• Шаблон WSJF для Google Sheets

---

prioplan.app не связан со Scaled Agile Framework или SAFe. Читайте их видение и манифест на https://www.scaledagileframework.com/