Сторипоинты измеряют сложность, а не время 🤔

История 📜

В 2017 году я впервые стал тимлидом, а в 2019-2022 годах я вёл курсы по тимлидству, параллельно сам проходя нелёгкую трансформацию из инженера в менеджеры. Всего провёл 3 потока. В первую очередь, курсы были нужны мне самому, чтобы структуризировать свои знания, которые я получал в основном из личного опыта и из очень разрозненных источников, так как tlroadmap тогда только формировался. Оказалось, что этот курс был полезен и для других людей.

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

На практике же я наблюдал, что практически всегда сторипоинты приравнивались ко времени, что, по сути, убивало их главную идею: абстрагирование от времени.

Вместе с тем, я до конца так и не мог понять, как можно оценивать сложность задач. Я понимал, как оценивать риски. Но сложность - нет.

Так было пока я не наткнулся на пример в скрам гайде (про мальчика и нейрохирурга, см. дальше). Это дало довольно серьёзную подсказку.

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

Наконец, вся картинка сложилась, когда я стал опираться на цель спринта и интересы бизнеса.

ДИСКЛЕЙМЕР

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

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

Неискоренимая проблема

Многие команды до сих пор путают сторипоинты с временем.

"Я сделую эту задачу примерно за 5 сторипоинтов" — часто можно услышать на груминге. И в этой фразе уже слышно, что человек оценивает время, и приравнивает сторипоинты к человеко-дням (или часам).

На самом же деле, задача на 5 дней может быть оценена в абсолютно любое количество сторипоинтов. Всё зависит от того, насколько она сложная.

Каноничный пример 🧠

Представьте команду из мальчика 7-8 лет и нейрохирурга.

У нас есть две задачи:

• Сделать несложную операцию на мозг
• Облизать 1000 марок

Обе задачи займут примерно час, но их сложность радикально отличается.

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

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

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

Примеры из разработки 💻

Задача 1: Скопировать готовый компонент из другого проекта со схожей архитектурой

• Время: 4 часа
• Сторипоинты: 1 sp (рутинная работа, известное решение)

Задача 2: Придумать архитектуру для нового типа компонентов

• Время: 4 часа
• Сторипоинты: 13 sp (творческая работа, множество неизвестных)

Задача 3: Написать простой SQL-запрос для отчета

• Время: 2 часа
• Сторипоинты: 2 sp (стандартная задача)

Задача 4: Оптимизировать медленный SQL-запрос в продакшене

• Время: 2 часа
• Сторипоинты: 8 sp (требует анализа планов выполнения, индексов, производительности)

Задача 5: Изменить цвет кнопки в интерфейсе

• Время: 30 минут
• Сторипоинты: 1 sp (простое изменение CSS)

Задача 6: Сделать чтобы нажатие на кнопку не фризило страницу

• Время: 30 минут
• Сторипоинты: 5 sp (требует понимания асинхронности и работы с DOM)

Видите парадокс? Задачи с одинаковым временем могут отличаться в сложности в 5-13 раз. Время выполнения не определяет сложность.

Шкала компетенций 📊

• 1 sp = интерн (тривиальные задачи, которые могут сделать все)
• 2 sp = джун
• 3 sp = джун+
• 5 sp = миддл
• 8 sp = миддл+
• 13 sp = сеньор
• 20 sp = лид/архитектор

Важно: сторипоинты ≠ грейды ⚠️

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

Почему это важно:

• В скраме команда работает как единое целое, а не как набор отдельных специалистов; если вы работаете по большей части независимо, то и синхронизация эстимаций вам по большому счёту не нужна
• Задача на 13 sp не означает, что её должен делать только сеньор
• Джуниоры могут выполнять сложные задачи при должном инвестировании в декомпозицию и дизайн со стороны команды
• Сеньоры могут брать простые задачи для помощи команде

Неправильно: "Это задача на 13 sp, значит её должен делать сеньор"
Правильно: "Это сложная задача, давайте обсудим, как мы будем её решать"

Важный принцип: Чем более конкретно расписан план реализации задачи, тем проще она становится. Детальная проработка снижает неопределённость и превращает сложную задачу в набор простых подзадач. Даже без декомпозиции очень сложную задачу можно превратить в простую, если написать детальный план имплементации.

Время в скраме ⏰

В скраме время регулируется только одним показателем: длительность спринта (как правило, две недели).

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

То есть... Зачем нам тогда сторипоинты, если они не помогают оценивать время?

Сторипоинты нужны для:

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

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

Но для этого нам нужно понимать, что именно мы планируем достичь за спринт.

Цель 🎯

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

Цель — это то, что команда планирует достичь за спринт.

И у нас получается следующая картина:

1. Мы знаем, что нужно сделать
2. Мы знаем, сколько времени у нас есть

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

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

Как это работает на практике:

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

Главная цель сторипоинтов: декомпозиция 🎯

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

Как сторипоинты помогают принимать решения о декомпозиции:

• 20+ sp = задача слишком сложная, требует декомпозиции
• 13 sp = можно попробовать декомпозировать для снижения рисков
• 8 sp = оптимальная сложность для большинства задач
• 5 sp и меньше = задачи готовы к выполнению

Практический пример:
Задача "Переписать систему аутентификации" оценивается в 20 sp. Команда понимает, что это слишком сложно, и разбивает на:

• "Спроектировать новую архитектуру" (8 sp)
• "Создать базовые компоненты" (5 sp)
• "Настроить миграцию данных" (5 sp)
• "Протестировать интеграцию" (3 sp)

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

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

Процесс оценки ⚡

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

Когда и как происходит оценка

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

Коллективное обсуждение и декомпозиция

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

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

Поиск локального оптимума

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

Фокус на бизнес-интересах

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

Управление техническим долгом в этом случае переносится на уровень бизнеса. Хотите больше технических задач? Объясните бизнесу, какую ценность они принесут.

Скрам всегда ставит во главу угла интересы бизнеса, и это правильно. Делайте как скрам.

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

Правильное понимание сторипоинтов помогает:

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

От сторипоинтов к времени 📈

Задачи переводятся во время с использованием статистических методов по историческим данным команды (метод монте-карло).

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

Справка: На практике команды используют velocity (среднее количество сторипоинтов за спринт) и burn-down charts для отслеживания прогресса. Бизнес перестаёт полагаться на оценки разработчиков в часах, и оперирует масштабами спринтов. Роудмаппинг становится более простым и значительно более гибким, так как роудмап можно менять хоть каждую итерацию.

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

Что делать дальше? 🚀

1. На следующем груминге спросите команду: "Насколько сложная эта задача?" вместо "Сколько времени займет?"

2. При планировании спринта фокусируйтесь на цели, а не на заполнении времени задачами

3. Если задача больше 8 sp — подумайте, можно ли её декомпозировать

4. Отслеживайте velocity команды, чтобы понимать реальную производительность

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

Сторипоинты в эпоху ИИ 🤖

В эпоху ИИ-ассистентов сторипоинты становятся идеальным инструментом для измерения "силы" ИИ-агента: мы оцениваем, насколько сложные задачи они могут решить.

Как это работает:

• ИИ-агент может решать задачи до определенного уровня сложности (например, до 5 sp)
• Задачи выше этого уровня требуют человеческого участия
• Понимая способности ИИ, мы знаем, до какой степени детализировать задачи для них

Практический пример:

• Задача "Написать простой SQL-запрос" (2 sp) - ИИ справится
• Задача "Оптимизировать медленный запрос в продакшене" (8 sp) - нужен человек
• Задача "Спроектировать архитектуру БД" (13 sp) - только человек

Сторипоинты становятся ватерлинией, ниже которой человек может не напрягаться.

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

Заключение

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

P. S.: Для желающих углубиться в тему - вот хорошая статья про сложность и способы её оценки.