Оценка задач в Scrum

Где в спринте происходит оценка

Формально Scrum не требует ни поинтов, ни покера — он требует, чтобы у элементов бэклога была оценка. Как её получать, команда решает сама.

На практике оценка живёт в двух местах. Первое — уточнение бэклога (refinement): регулярная встреча, где разбирают то, что придёт в работу через спринт-другой. Второе — планирование спринта, где уже понятные задачи разбирают на конкретную работу.

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

Оценка — не обязательство

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

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

Как из оценок получается план

Команда считает velocity — сколько поинтов она доводит до готовности за спринт. Через три-четыре спринта видно и среднее, и разброс, и на них уже можно опираться.

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

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

Кто оценивает

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

Владелец продукта в раунде участвует, но не голосует: его дело — рассказать, что нужно, и ответить на вопросы. Разработчики, тестировщики и все, чья работа входит в «готово», голосуют наравне.

Что обесценивает оценку

Одни и те же ошибки повторяются в командах любого размера.

• Оценка как KPI. Метрика, за которую отвечают, перестаёт описывать реальность — она начинает описывать желание отчитаться.
• Сравнение команд по velocity: у каждой своя шкала, общего смысла в сравнении нет.
• Оценка задачи без описания. Числа, поставленные вслепую, ломают прогноз надолго.
• Пересчёт оценок задним числом ради «красивой» статистики.
• Оценка всего бэклога до горизонта. Устаревает быстрее, чем пригождается.

Когда оценки можно не считать

Есть команды, которые обходятся без поинтов вовсе: они дробят все задачи до примерно одинакового размера и считают их количество (подход #NoEstimates). Прогноз получается не хуже, а времени на оценку уходит меньше.

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