OKR и Scrum. Как совместить цели компании и спринты команды

OKR внедрили, Scrum работает, а между ними постоянное трение. Квартальные Objectives задают одно направление, а беклог спринта живёт своей жизнью. К концу квартала Key Results достигнуты на 40%, и никто толком не понимает, почему: вроде бы работали много, спринты закрывали, velocity стабильная.

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

Почему OKR и Scrum конфликтуют

OKR работают на горизонте квартала. Objectives формулируются раз в три месяца, Key Results измеряют прогресс к этим целям. Логика OKR: определить направление и дать командам свободу в выборе способов достижения.

Scrum работает на горизонте спринта, обычно две недели. Sprint Goal формулируется на planning, команда берёт обязательства на ближайший спринт. Логика Scrum: короткие циклы обратной связи и адаптация.

Конфликт возникает на стыке. OKR говорят: «В этом квартале увеличиваем retention на 5%». Scrum говорит: «Что мы делаем в ближайшие две недели?» Между этими двумя уровнями часто нет связующего звена. Product Owner планирует спринт, ориентируясь на беклог, который наполняется из десяти источников. OKR становятся одним из этих источников, причём далеко не всегда самым громким.

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

Как это работает, когда работает

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

Sprint Goal привязан к OKR. Каждый спринт имеет цель, которая явно связана с одним из Objectives. Связь может быть прямой («этот спринт мы работаем над фичей, которая влияет на KR по retention») или косвенной («этот спринт мы закрываем техдолг, который блокирует работу над retention»). Главное, чтобы связь была осознанной и проговорённой на planning.

Еженедельный или двухнедельный check-in по OKR. Ждать до конца квартала, чтобы понять, двигаются ли Key Results, слишком долго. Короткий check-in (15-20 минут) каждые одну-две недели позволяет вовремя заметить, что команда работает активно, а KR стоит на месте. Это сигнал пересмотреть приоритеты беклога.

Product Owner отвечает за связь между OKR и беклогом. Именно product owner (или product manager) обеспечивает, чтобы задачи в беклоге работали на квартальные цели. Это требует дисциплины: каждая задача, которая попадает в спринт, проходит через фильтр «как это связано с нашими OKR?». Задачи, которые не связаны, могут быть важными, но они должны конкурировать за место в спринте на равных основаниях.

OKR формулируются с учётом capacity команды. Если команда тратит 40% времени на поддержку, баги и ad-hoc запросы, Key Results должны это учитывать. Один из частых источников разочарования: OKR формулируются из расчёта, что вся команда 100% времени работает над стратегическими задачами. На практике это почти никогда не так.

Типичные ловушки

Слишком много Objectives. Если у команды пять Objectives на квартал, де-факто у неё нет ни одного. Каждый спринт приходится выбирать, на какой OKR работать, и выбор делается ситуативно. Одного-двух Objectives на команду обычно достаточно.

Key Results, которые команда не может измерить. «Увеличить NPS на 10 пунктов» звучит хорошо, но если команда получает данные по NPS раз в квартал, она весь квартал работает вслепую. Key Results должны быть измеримы с частотой, позволяющей корректировать курс.

OKR как KPI. OKR задуманы как амбициозные цели, достижение 70% считается хорошим результатом. Если OKR превращаются в KPI, к которым привязана оценка эффективности, команды начинают формулировать заведомо достижимые цели, и весь смысл OKR пропадает.

Где развивать навыки

Программа Agile Project Management разбирает, как выстраивать прозрачность для бизнеса, управлять ожиданиями и работать с метриками, которые связывают операционную работу команды со стратегическими целями. Сертификат ICP-APM от ICAgile подтверждает эти компетенции.

Product owner и продакт-менеджерам, которые отвечают за связку OKR и беклога, будет полезна программа Advanced Product Ownership. Приоритизация, управление беклогом, принятие решений на основе данных.

Базовая программа Certified Agile Professional даёт понимание agile-подходов в целом и помогает видеть, как разные элементы процесса (спринты, OKR, метрики) связаны друг с другом.