Оценивайте задачи не в часах, а сравнением сложности: используйте story points или t-shirt sizes, калибруйте шкалу на эталонных примерах и применяйте одну и ту же логику на планировании. Так оценка задач в разработке становится повторяемой, а прогнозируемость разработки растёт за счёт стабильной velocity и более ровного бёрндауна.
Что важно учесть перед оценкой задач
- Оценка - это инструмент планирования и прогнозирования, а не обещание точной даты.
- Сравнивайте задачи между собой, а не переводите всё в часы "по ощущениям".
- Сначала договоритесь, что именно оцениваете: объём, сложность, риск или неопределённость.
- Фиксируйте критерии "готово к оценке" (DoR) и "готово" (DoD), иначе разброс будет расти.
- Не смешивайте в одном числе разработку, тестирование, ревью и деплой, если процесс у команд разный.
- Поддерживайте бэклог "в форме": крупные элементы дробите до управляемой гранулярности.
Сравнение подходов: story points vs t-shirt sizes
Story points подходят, когда команда работает спринтами, хочет стабилизировать скорость и использовать story points оценка задач для прогнозов. Они хорошо работают при регулярной поставке, схожем составе команды и привычке сравнивать задачи по сложности.
T-shirt sizes уместны для быстрого груминга и раннего приоритезационного отбора: t-shirt sizes оценка задач помогает быстро отделить "мелочь" от "крупняка", не вдаваясь в детали до готовности требований.
- Когда story points не стоит делать: вы пытаетесь "перевести SP в часы" для каждого исполнителя; задачи постоянно "размыты" и без DoR; команда часто меняется и не успевает калиброваться.
- Когда t-shirt sizes не стоит делать: вы планируете спринт по размерам без дробления; размер превращается в дискретные "часы"; слишком много задач попадает в XL и остаётся непрозрачным.
Практичный компромисс: на раннем этапе - t-shirt sizes, перед взятием в спринт - переход к story points и уточнение.
Как выбрать масштаб и гранулярность оценки
Цель - выбрать такую шкалу, при которой команда умеет уверенно сравнивать задачи и не тратит на оценку больше, чем на прояснение требований.
Выбор шкалы: рекомендации для intermediate
- Для story points: используйте ограниченную шкалу (часто - "фибоначчи-подобную"), чтобы не создавать ложную точность. Важно не конкретное множество чисел, а правило: следующий шаг должен быть заметно "другого порядка сложности".
- Для t-shirt sizes: S/M/L/XL (+ при необходимости XS/XXL). Договоритесь, что означает каждый размер через примеры задач.
Нужные входные данные и доступы
- Требования: краткое описание, бизнес-цель, ограничения, критерии приемки, границы "входит/не входит".
- Технический контекст: ссылки на код/модули, архитектурные ограничения, интеграции, нефункциональные требования.
- Инструменты: трекер задач (Jira/YouTrack/и т.п.), доска спринта, история выполненных задач для калибровки, доступ к логам/метрикам при оценке рисков.
- Договорённости процесса: Definition of Ready/Done, политика тестирования, обязательность ревью, схема релизов.
Гранулярность: до какого уровня дробить
- Элемент должен помещаться в один спринт с учётом реальной доступности команды.
- Если задача получилась "самая верхняя категория" (например, XL или максимальные SP), дробите по вертикальным срезам (ценность) или по рискам (самое рискованное - отдельной задачей).
- Если оценка "гуляет" из-за неизвестности, фиксируйте отдельный discovery/spike вместо попытки угадать.
Практика планирования: покер планирование и быстрые сессии
Ниже - безопасный, повторяемый сценарий, который помогает проводить планирование спринта оценка задач без затяжных обсуждений и "торгов" вокруг цифр.
Мини-чеклист подготовки перед сессией
- Проверьте, что задачи соответствуют DoR (минимальный набор требований и критериев приемки).
- Подготовьте 2-4 эталонные задачи с согласованной оценкой (якоря шкалы).
- Ограничьте WIP по оценке: берите небольшой пакет задач, которые реально могут попасть в ближайший спринт.
- Убедитесь, что на сессии есть нужные роли: тот, кто отвечает за требования, и люди, которые будут выполнять работу.
- Заранее отметьте задачи с внешними зависимостями и неизвестностями (чтобы не "тонуть" в них на сессии).
-
Откройте контекст и критерии приемки. Владелец задачи кратко формулирует цель, границы и проверяемые критерии. Команда задаёт только уточняющие вопросы, которые влияют на объём/сложность.
- Если критериев приемки нет - задача не оценивается, возвращается на доработку.
- Сравните с эталонами, а не "вспоминайте часы". Укажите, на какую якорную задачу похоже: "это примерно как тот рефакторинг на N SP, но с большим риском интеграции". Это стабилизирует story points оценка задач.
- Сделайте скрытое голосование. Каждый участник выбирает оценку одновременно (planning poker) или пишет размер/points в чат с одновременной отправкой. Скрытость снижает эффект авторитета.
-
Разберите только расхождения. Обсуждают участники с минимальной и максимальной оценкой: что они увидели по-разному (объём, риск, тестирование, деплой). Остальные слушают и добавляют только новые факты.
- Если расхождение из-за неизвестности - выделите spike/исследование.
- Если расхождение из-за объёма - предложите разбиение на 2-3 задачи.
- Переголосуйте один раз и зафиксируйте решение. Повторное голосование - короткое; дальше либо принимаете консенсус, либо переносите задачу на уточнение. В описании задачи кратко фиксируйте, что именно "включено" в оценку (например, "включая e2e-тест и деплой в staging").
- Соберите спринт по capacity и рискам. Подбирайте задачи на спринт исходя из доступности людей и исторической скорости. Отдельно отметьте задачи с рисками/зависимостями и не ставьте весь спринт на "красные зоны".
Калибровка оценок команды и поддержание консистентности
- У команды есть 2-4 "якоря" шкалы, и все могут объяснить, почему они такие.
- Оценки ставятся по одинаковым правилам: что входит (ревью, тестирование, документация, деплой) и что не входит.
- Задачи с высокой неопределённостью помечаются и не маскируются большой оценкой - для них есть spike/исследование.
- Оценка пересматривается только при изменении объёма/условий, а не из-за "не уложились".
- Есть регулярная короткая ретроспектива оценок: 10-15 минут раз в спринт на 2-3 задачи с наибольшим отклонением.
- Крупные элементы не проходят в спринт без дробления и уточнения критериев приемки.
- Сравнение идёт с примерами из вашей истории, а не с абстрактными "идеальными задачами".
- Новые участники проходят вводную по шкале и примерам, прежде чем активно голосовать.
Использование оценок для прогнозирования релизов и бёрндауна
Оценки полезны, когда вы опираетесь на фактическую скорость команды и одинаковый способ считать выполненное. Это напрямую влияет на прогнозируемость разработки, но легко ломается типовыми ошибками.
- Переводить points в часы "по коэффициенту" и обещать даты как по смете: points - относительная мера, не трудозатраты каждого человека.
- Менять правила учёта done в середине проекта (например, считать done без тестов, а потом требовать тесты) - бёрндаун станет нерелевантным.
- Смешивать в одной velocity разные типы работ без меток (фичи, баги, техдолг, поддержка) и потом удивляться скачкам.
- Планировать спринт "под максимум", игнорируя встречи, поддержку, отпуск и параллельную работу - падение выполнения будет системным.
- Игнорировать зависимости и ожидания внешних команд: формально points набраны, фактически релиз стопорится.
- Держать в спринте много незавершёнки (carry-over): бёрндаун рисует "плато", а причины размываются.
- Использовать velocity как KPI для давления на команду: это провоцирует завышение/занижение оценок и ухудшает качество.
- Считать "прогноз релиза" без пересмотра при изменениях скоупа: любые изменения должны пересчитывать прогноз.
Как учитывать технический долг, исследование и риск
- Отдельные задачи техдолга со своей оценкой. Уместно, когда долг понятен (что меняем, где, критерии готовности) и его можно выполнить в рамках спринта без "раскопок".
- Spike/исследование с timebox. Уместно, когда неизвестность доминирует: цель - снизить риск и прояснить решение, выход - краткий результат (варианты, прототип, список работ), а не "почти готовая фича".
- Риск-буфер на спринт. Уместно при большом числе внешних зависимостей или нестабильной среде; буфер фиксируется явно (часть capacity), а не прячется в завышенные оценки.
- Двухфазная оценка: сначала t-shirt sizes для сортировки, затем story points перед взятием в работу. Уместно для крупных бэклогов, где важно быстро понять "масштаб", но точность нужна только ближе к реализации.
Ответы на типичные затруднения при оценке задач
Почему мы постоянно спорим о цифрах, хотя задачи похожи?
Обычно различаются предположения: что входит в done, какие тесты нужны, есть ли миграции/интеграции. Зафиксируйте DoD и добавьте 2-4 эталонные задачи как якоря шкалы.
Можно ли использовать story points как эквивалент часов?
Не стоит: это создаёт ложную точность и ломает смысл относительной оценки. Если нужны часы для внешнего контракта, делайте отдельную оценку трудозатрат и не смешивайте её со story points.
Мы делаем t-shirt sizes: как перейти к планированию спринта?
Оставьте размеры для раннего груминга, а перед спринтом переводите выбранные задачи в points после уточнения критериев. Критично, чтобы крупные L/XL были заранее раздроблены.
Что делать, если задача "слишком неизвестная" для оценки?
Оформите spike с timebox и ожидаемым результатом (варианты решения, риски, список работ). После spike вернитесь к оценке уже по прояснённому объёму.
Как учитывать тестирование и ревью в оценке?
Договоритесь, что оценка включает полный цикл до done (код, ревью, тесты, исправления, подготовка к деплою) или явно разделяйте задачи по типам работ. Главное - последовательность и единые правила.
Почему бёрндаун "не похож на реальность", хотя мы всё оцениваем?
Чаще всего меняются правила done, много carry-over или спринт перегружен без учёта реальной capacity. Стабилизируйте учёт done и планируйте по факту доступности, а не по желанию.
Как понять, что наша оценка задач в разработке стала лучше?
Признаки: меньше пересмотров оценок без изменения скоупа, меньше задач "не влезло", стабильнее velocity и проще объяснять прогноз. Это и есть практический рост прогнозируемости разработки.
