Story points: как оценивать задачи без перевода в часы

Баллы сравнивают работу, а не обещают длительность

Story points — относительная оценка размера работы внутри команды.

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

Представим учебную команду, которая развивает сайт мастерской. Ей нужно добавить поле в форму, сделать перенос записи и подключить неизвестный внешний сервис. Все три задачи могут называться «небольшими», пока участники не сравнят реальные условия.

Как выбрать эталонную задачу

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

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

Если состав команды или продукт заметно изменился, старые ориентиры могут потерять смысл. Не нужно поддерживать видимость абсолютной шкалы. Обсудите новые примеры и осторожно относитесь к сравнению показателей до и после изменения.

Пример относительной оценки

Оценка 5 не означает «пять часов» и не даёт точного отношения длительностей. Она сообщает, что команда ожидает более крупную работу по сравнению с эталоном. Даже одинаковые по размеру задачи могут ждать внешнего решения разное время.

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

Почему один участник поставил 3, а другой 13

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

Не усредняйте 3 и 13 автоматически. Среднее не отвечает на вопрос, входит ли защита от повторной записи. После уточнения команда может выбрать 5, разделить историю или сначала провести исследование. Полезный результат обсуждения — ясность, а не компромиссное число.

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

Когда задачу лучше разделить

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

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

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

Definition of Done помогает договориться, что именно команда включает в завершённую работу.

Как использовать прошлые данные для прогноза

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

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

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

Где сохранить рабочий результат

В Sinqly можно создать задачу «Уточнить объём переноса записи» и добавить в описание эталон сравнения, сценарии и неизвестные условия; пример не предполагает встроенного расчёта story points; регистрация бесплатная.

КомпьютерТелефон

Рассмотреть экран ↗

Закрыть ×

Реальная карточка задачи Sinqly из банка скриншотов: показано поле описания на другом учебном примере. Содержание из этой статьи переносится вручную; отдельного специализированного модуля на снимке нет.

Небольшой эксперимент для команды

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

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