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

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

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

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

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

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

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

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

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

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

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

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

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

Те, кто будет делать работу. Если оценку ставит менеджер, аналитик или архитектор со стороны, она превращается в норму, спущенную сверху, и команда за неё не отвечает.

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

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

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

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

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

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

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