Story Points или часы: как команды оценивают задачи

Вячеслав Степанов — проджект-менеджер, ментор · 19 октября 2026

Одни команды говорят «задача на три дня», а другие: «задача на пять поинтов». Новичок часто думает, что один из способов правильный, а другой устарел. Оба нормальные: команды выбирают тот, который подходит их составу и привычкам. Проджекту нужно разбираться в обоих, потому что в одной компании оценивают в часах, в другой в Story Points, а на собеседовании спросят про то и другое.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Зачем вообще оценивать задачи

Оценка нужна, чтобы ответить на два вопроса: сколько работы команда возьмёт в спринт и когда будет готова фича. Без оценок планирование превращается в «возьмём побольше, как-нибудь успеем», а сроки для бизнеса — в догадки.

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

Оценка в часах и днях

Самый понятный способ: исполнитель говорит, сколько времени займёт задача, — «два дня», «шесть часов». Такая оценка понятна всем, включая бизнес, и её легко сложить с рабочим временем человека на спринт.

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

Слабое место в том, что люди плохо угадывают абсолютное время, а цифра «6 часов» звучит точнее, чем она есть. Поэтому к оценке во времени обычно добавляют запас на ревью, помощь коллегам и прерывания.

Story Points

Story Points (поинты, сторипоинты) — относительная оценка сложности задачи. Команда сравнивает задачи между собой: «эта примерно как та, что мы делали на прошлой неделе», «эта в два раза сложнее». Поинты учитывают сразу объём работы, сложность и неопределённость.

Чаще всего используют шкалу, похожую на числа Фибоначчи. Если оценка дотягивает до 13, задачу делят на части: спор «это 11 или 13» бесполезен, а большая задача почти всегда прячет неизвестное.

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

Когда какой способ подходит

Правильного для всех ответа нет. Хороший признак — команда сама выбрала способ и регулярно сверяет оценки с фактом. Плохой — способ навязан сверху и цифры никто не проверяет.

Planning Poker

Planning Poker придумал Джеймс Греннинг в 2002 году, а популярным его сделал Майк Кон в книге «Agile Estimating and Planning» (2005). Каждый участник держит колоду карт со шкалой и после обсуждения задачи кладёт свою оценку рубашкой вверх. Карты открывают одновременно, чтобы никто не подстраивался под чужую цифру.

Если оценки близкие, берут среднее или большее и идут дальше. Сильный разброс — главная ценность покера: тот, кто поставил много, видит риск, которого не заметили другие. Если бы его не проговорили, он всплыл бы посреди спринта.

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

Кто даёт оценку

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

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

От оценок к плану спринта

Сама по себе оценка ничего не решает, её сравнивают с ёмкостью команды. При оценке во времени считают рабочие часы каждого человека за вычетом встреч и запаса. При оценке в поинтах смотрят на velocity: сколько поинтов команда фактически закрывала в последних спринтах. Оба расчёта с примерами есть в статье про спринт, а как разложить задачи по дням — в статье про диаграмму Ганта.

Как ответить на собеседовании

Вопрос «в чём ваша команда оценивает задачи?» проверяет, понимаешь ли ты логику, а не помнишь ли модное слово. Сильный ответ звучит примерно так: «Мы оцениваем в днях, потому что в каждой роли по одному человеку и бизнесу нужны понятные даты. Со Story Points знаком: это относительная оценка по шкале Фибоначчи, ёмкость считают по velocity прошлых спринтов. Если команда вырастет и в ролях станет по несколько человек, перейдём на поинты и Planning Poker».

Такой ответ показывает, что ты знаешь оба способа, понимаешь, почему выбран один из них, и не считаешь другой ошибкой.

Типичные ошибки

• Переводить поинты в часы по курсу. «Один поинт — четыре часа» убивает смысл относительной оценки. Если нужны часы, оценивай сразу в часах.
• Сравнивать velocity разных команд. У каждой команды свой масштаб поинтов. Помогает сравнение команды только с ней самой в прошлом.
• Проджект оценивает за команду. «Ну это, наверное, три дня» — это догадка. Решается так: оценку даёт исполнитель, а проджект спрашивает обоснование.
• Усреднять оценки разных ролей. Средняя цифра бэкенда и тестирования ничего не значит. Выход: держать набор оценок по частям.
• Требовать роста velocity. Команда начинает завышать оценки, и цифры теряют смысл. Чтобы этого не было, используй velocity для планирования, а не как цель.

Частые вопросы