Что такое Story Points? Как оценивать в них задачи? Как можно это стандартизировать?
Казалось бы, заезженная тема, но в наших командах вопросы возникают снова и снова, особенно с добавлением новых людей. Вот максимально краткая шпаргалка.
Добиться универсальной шкалы для оценки задач между разными командами очень сложно, потому что оценка зависит от количества людей в команде и общего уровня экспертизы. Поэтому принято считать, что одна команда оценивает задачи, например, в "бананах", а другая — в "клубничках". Можно попытаться вычислить "кросс-курс", но если компания начинает сводить всех к универсальной системе, это всегда приводит к оценке в человеко-часах, а это ошибка.
Почему ошибка?
В Agile/Scrum Story Points оценивают сложность задачи, а потом выбирается подходящий исполнитель. Допустим, есть задача, оценённая в 13 SP. Её можно дать исполнителю (или команде) без экспертизы, и тогда выполнение займёт две недели, или поручить опытному эксперту (или команде), и задача будет решена за неделю, а то и за три дня. Подход с человеко-часами не учитывает разницу в экспертизе, а значит, неприменим в индустриях высокоинтеллектуального труда.
Поэтому первое утверждение, которое высекаем в камне
Story Points - это оценка сложности, а не время.
Что такое Story Points?
- SP — это универсальная "весовая категория" для задач.
- Мы оцениваем, насколько задача трудозатратна относительно других.
- Важно: это не только кодинг, но и тестирование, ревью, разбор требований, исправление ошибок и т.д.
На что мы смотрим при оценке?
В вашей практике оценивайте задачи с учётом трёх факторов:
- Объем работы. Сколько строк кода или модулей нужно написать?Сколько тестов придётся сделать? Автоматизация или ручное тестирование? Затрагивает ли задача много систем или сервисов?
- Сложность. Насколько "умный" код нужно написать? Есть ли алгоритмы или оптимизации? Работаете с новым стеком технологий или API, где потребуется время на изучение?
- Неопределённость и риски. Насколько понятен тикет (User Story / Task и т.д.)? Хорошо ли описаны Acceptance Criteria? Есть ли внешние зависимости (другие команды, ручки API, дата-специалисты)?
Как использовать шкалу от 1 до 21 SP
Важно придерживаться критериев, чтобы не путаться:
1–5 SP: Простые задачи
- 1 SP — очень легко: мелкий фикс, настройка конфигурации, исправление опечатки. Часто за 1 SP берётся мельчайшая эталонная задача, что нужно сделать, чтобы выполнив все обязательные ритуалы (регресс, выкатка на прод и т.д.) изменить простую текстовку на проде.
- 3 SP — типичная задача, например, добавить метод или кнопку в UI.
- 5 SP — чуть сложнее, например, реализовать REST API-эндпоинт с базовым тестированием.
8–13 SP: Средние задачи
- 8 SP — сложная задача, например, связать два микросервиса, где нужно продумать архитектуру.
- 13 SP — задача с неопределённостями: интеграция с внешним API, где потребуется разбираться в сторонней документации.
21 SP: Очень крупная задача
- Это задачи с большим количеством неизвестных и/или интеграций, например: Реализация нового модуля системы.Миграция большого объёма данных.Нужны исследования перед началом работы.
Если задача требует больше 21 SP, это сигнал: её нужно разбить на более мелкие.
Как оценивать в команде
- Выберите эталон. Определите типовую задачу для каждого уровня (1, 3, 8 SP) и используйте её для сравнения.
- Используйте покер планинг физические карты или онлайн сервисы: planningpokeronline.com, www.pointingpoker.com, www.scrumpoker-online.org/en/. Задача проговаривается вслух, затем каждый член команды оценивает задачу, затем команда вскрывается. Так вырабатывается оценка сложности задачи командой, а не отдельным экспертом
- Если оценки сильно разные, важно проговорить крайние оценки, выслушать аргументы, технические сложности, неопределённости, влияние на другие модули, а затем можно повторить голосование, до тех пор пока команда не определится.
- Ищите консенсус. Если кто-то настаивает на высокой оценке (например, 13 вместо 8), уточните: "Почему?" Возможно, он видит риски, которые упустили другие.
- Планинг покер позволяет стандартизировать подход к оценкам внутри команды до такой степени, что даже представители не разработческих ролей, например дизайнеры в командах будут способны выдавать оценку сложности будущей задачи "на глаз"
Почему это важно
- Планирование: Помогает спрогнозировать объём работы, который команда реалистично выполнить за спринт.
- Прозрачность: Каждый понимает, почему одна задача "тяжелее" другой.
- Управление неопределённостью: Вы сразу учитываете возможные риски по всем слоям разных компетенций.
Пример задач на разработку ПО
- 1 SP: Поправить баг в стилях (например, выравнивание кнопки), изменить текстовку, разрешить спайку (Spike - простая аналитическая исследовательская задача).
- 3 SP: Добавить новый фильтр в существующем списке.
- 8 SP: Разработать экран с интерактивными элементами и логикой.
- 13 SP: Интеграция нового стороннего сервиса.
- 21 SP: Полный редизайн модуля, включая фронтенд, бэкенд и тестирование.
Чёткие границы и ориентиры помогут всей команде понимать, как оценивать задачи и планировать спринты реалистично.
Больше экспертизы и мудростей в телеграм канале "Корпоративный предприниматель"