Оценка и планирование: story points и velocity

← назад к разделу

Любой, кто хоть раз называл срок «сделаю за два дня», знает, чем это кончается. Проходит два дня — задача готова наполовину, потому что всплыл забытый случай, сломался соседний сервис или вмешалась встреча, которую нельзя было пропустить. Оценка в часах выглядит точной, но эта точность обманчива: мы плохо предсказываем время, зато неплохо чувствуем, что одна задача крупнее другой. На этом наблюдении и строится оценка в Agile — story points, Planning Poker и velocity. Разберём, как это работает и, главное, где команды чаще всего спотыкаются.

Почему оценка в часах врёт

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

• Разные люди — разная скорость. Задача, которую опытный разработчик закроет за час, у новичка займёт день. Чью оценку записывать в план?
• Неопределённость прячется в деталях. «Добавить поле в форму» звучит на 15 минут, пока не выясняется, что поле надо валидировать, сохранять в двух местах и показывать в отчёте.
• Мешают перерывы и переключения. Реальный рабочий день — это не восемь часов чистого кода. Встречи, обсуждения, помощь коллеге. Оценка в часах притворяется, что всего этого нет.
• Число становится обещанием. Стоит назвать «4 часа» — и это превращается в обязательство, за срыв которого будто бы стыдно, хотя вы просто угадывали.

Ключевая идея Agile-оценки: мы гораздо лучше сравниваем, чем измеряем. Спросите, сколько минут идти до магазина — ответы разойдутся. Спросите, что дальше — магазин или парк — и все ответят одинаково. Это и есть относительная оценка: не «сколько времени», а «насколько крупнее по сравнению с чем-то знакомым».

Что именно оценивают: строка бэклога

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

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

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

Почему без этого оценка не работает:

• Сравнивать можно только сравнимое. Points — относительная мера; относительно чего, если у одной строки понятен результат, а у другой нет?
• Неопределённость уходит в число вслепую. Разработчик, не знающий границ, ставит с запасом. Запас у каждого свой, и разброс на встрече получается не из-за разного понимания работы, а из-за разного понимания задачи.
• «Готово» становится предметом спора. Без критериев приёмки задача закрывается тогда, когда автор решил, что достаточно, — и её points попадают в velocity, не означая результата.

Практическое правило: строка без критериев приёмки не оценивается. Её не «оценивают с запасом», а возвращают на уточнение. Подробнее про форму истории, дробление и признак готовности к работе — в статье про Scrum, в разделе про то, откуда берётся карточка.

Story points — оценка сложности и объёма относительно эталона

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

Работает это так. Команда выбирает эталонную задачу — небольшую, понятную, которую все делали и хорошо представляют. Ей назначают, например, 2 points. Дальше каждую новую задачу сравнивают с эталоном: «это примерно как эталон» → 2, «раза в три больше и с непонятным куском» → 5 или 8.

Обычно берут не подряд идущие числа, а последовательность, где шаг растёт — например, ряд, похожий на числа Фибоначчи:

Растущий шаг не случаен. Чем крупнее задача, тем хуже мы её понимаем, поэтому и точность оценки падает — различать «21 или 22» бессмысленно, а «13 или 21» — осмысленно. Если задача тянет на 13 и выше, это сигнал разбить её на несколько поменьше: большие оценки почти всегда прячут неразобранные детали.

В готовых колодах ряд слегка подправлен под практику: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Ноль — «работы тут нет», половинка — «совсем мелочь». Сверх чисел в колоде есть ещё две карты: «?» и «перерыв». Знак вопроса не украшение: это способ сказать «мне нечем оценивать, я не понял задачу», и на встрече он полезнее любого числа наугад.

Важное свойство points: они «свои» для каждой команды. Пятёрка в одной команде и пятёрка в другой — это не одно и то же, потому что эталон у всех свой. Сравнивать points между командами бессмысленно (к этому ещё вернёмся).

Planning Poker — команда оценивает вместе

Оценивать в одиночку опасно: один человек видит только свой кусок работы. Planning Poker — простой ритуал, который заставляет высказаться всех.

Ход такой:

1. Ведущий зачитывает задачу, команда задаёт вопросы, пока смысл не станет ясным.
2. Каждый, кто будет делать эту работу, втайне выбирает оценку — картой из колоды или пальцами. Product Owner отвечает на вопросы, но карту не кладёт: его число сразу становится планкой, а ритуал ровно от этого и защищает. Scrum Master ведёт встречу и тоже не оценивает.
3. Все вскрывают выбор одновременно — чтобы никто не подстраивался под «авторитетного» коллегу.
4. Если оценки близки — берут общую и идут дальше.
5. Если разошлись сильно (кто-то поставил 2, кто-то 13) — обсуждают именно это расхождение.

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

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

Velocity — сколько команда закрывает за спринт

Оценили задачи в points, взяли их в спринт, довели до готовности. Сумма points завершённых задач за спринт называется velocity. Если за спринт закрыли задачи на 8, 5, 3 и 5 points, velocity этого спринта — 21.

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

Одно число ни о чём не говорит, а вот несколько подряд — уже да. Возьмём последние спринты: 19, 22, 20, 21, 18. Видно, что команда стабильно закрывает около 20 points. Это и есть рабочий инструмент планирования: в backlog осталось задач на 100 points → при velocity ~20 понадобится примерно пять спринтов. Не гарантия, а обоснованный прогноз, который постепенно уточняется.

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

живой пример

velocity = [19, 22, 20, 21, 18]  # points, закрытые за последние пять спринтов
backlog = 100                    # points осталось в backlog
average = sum(velocity) / len(velocity)
print(f"среднее: {average:.0f} points за спринт")
print(f"прогноз: от {backlog / max(velocity):.1f} до {backlog / min(velocity):.1f} спринтов".replace(".", ","))

Ровные «пять спринтов» превращаются в «от 4,5 до 5,6» — и это честнее, потому что точной даты здесь взять неоткуда. Только считать это расчётом не стоит: деление на лучший и худший спринт — прикидка на салфетке. За пять спринтов колебания частично гасят друг друга, так что настоящий разброс уже вилки, зато неучтённые события — отпуск, инцидент, ушедший человек — его раздвигают. Строгий ответ дают иначе: многократно разыгрывают будущее по истории завершённых задач и смотрят, в какой срок укладывается, скажем, девять прогонов из десяти. Новой команде velocity вообще недоступна первые несколько спринтов — ей просто не с чем сравнивать, эталон и ритм ещё не устоялись.

И главное, ради чего стоит держать velocity: это инструмент прогноза для самой команды, а не оценка её работы для кого-то сверху. Как только velocity начинают требовать «повышать» — она ломается.

Мощность команды на спринт

Среднее за пять спринтов — 20 points. Значит, в следующий спринт берём 20? Не всегда, и это первое, что корректирует прогноз.

Мощность (capacity) — сколько команда реально может сделать именно в этом спринте. Считают её грубо, по доступному времени:

Пять человек, двухнедельный спринт, средняя скорость 20 points. В этом спринте один в отпуске всю неделю, в календаре два праздничных дня, один дежурит. Доступного времени примерно на две трети — значит, в спринт разумно взять около 13–14 points, а не 20.

Три оговорки, без которых мощность превращается в фикцию:

• Мощность считают в доступном времени, а не в points. Points — мера задачи, часы — мера доступности. Их не смешивают: сначала прикидывают, какая доля команды доступна, потом умножают на среднюю скорость.
• Мощность не прогноз, а поправка к нему. Среднее описывает обычный спринт; мощность говорит, насколько этот спринт не обычный.
• Стопроцентной загрузки не бывает. Встречи, ревью, помощь коллеге, разбор упавшего в проде — это не «непроизводительное время», а обычная работа. Команда, планирующая на сто процентов доступного времени, планирует срыв.

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

«Нам всё равно нужна дата»

Настоящий сюжет темы начинается здесь. Команда объяснила про относительные оценки и вилку, а заказчик отвечает: «Я это понял. Мне нужно одно число, потому что я договариваюсь с партнёром на конкретный день».

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

1. Признать, что дата нужна. Дата нужна не из вредности: под неё договариваются, покупают рекламу, ставят людей. Спор не о том, нужна ли дата, а о том, что за ней стоит.

2. Назвать дату вместе с её вероятностью. Не «сделаем 15-го», а «к 15-му успеем примерно в половине случаев, к 29-му — почти наверняка». Дальше выбирает заказчик: ранняя дата с риском или поздняя со спокойствием. Это не уход от ответа, а перевод разговора из «когда» в «с какой уверенностью», где числа берутся из истории команды, а не из желания.

3. Спросить, что делаем с датой, если не успеваем. Ответ на этот вопрос важнее самой даты, и вариантов всего три: сдвинуть дату, урезать объём, добавить людей (последнее почти никогда не помогает в срок). Договариваться надо заранее, а не в последнюю неделю. Практически самое сильное предложение звучит так: дату фиксируем, объём делаем управляемым — к этому дню гарантированно работает основное, а вот этот список — по остатку.

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

Чего делать не стоит: называть дату «с запасом на всё» — запас будет съеден, потому что работа расширяется под отведённое время; и соглашаться на дату, названную сверху, молча — молчание читается как обязательство.

Чем ещё меряют, кроме points

Points — не единственная и не всегда лучшая мера. Три ходовые альтернативы стоят на том же уровне, а не «вместо серьёзной оценки».

Размеры футболок (S / M / L / XL). Тот же относительный счёт, но без числа. Плюс — на числа не тянет арифметика: никто не складывает три M и не требует «повысить среднее». Годится для грубой прикидки крупного, для сортировки очереди и для разговора с заказчиком. Минус — прогноз по ним считать неудобно, поэтому крупное часто прикидывают футболками, а то, что идёт в работу, оценивают точнее.

Счёт задач за период. Не оценивать вовсе, а считать, сколько строк бэклога команда доводит до готового за неделю. Работает при одном условии: задачи разбиты до сравнимого размера — разброс в несколько раз терпим, в десятки нет. Условие не бесплатное, дробить приходится дисциплинированно, зато ритуал оценки исчезает целиком.

Пропускная способность потока. Ближайший родственник счёта задач и прямой аналог velocity из потокового подхода: сколько карточек проходит доску за неделю, и прогноз считается делением очереди на это число. Это и есть связка с подходом #NoEstimates: он не «против оценок вообще», он предлагает мерить то же самое, но в штуках, а не в баллах сложности. Как из такого счёта получают вилку и более честный розыгрыш на истории — в статье про Kanban.

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

Когда оценивать не нужно

Оценка нужна для решения. Нет решения — нет смысла в оценке, и это не лень, а экономия недели работы в год.

Исследовательская задача. «Разобраться, можно ли использовать этот способ поиска» — оценить нельзя в принципе: неизвестен объём того, что найдётся. Вместо оценки ставят ограничение по времени: два дня, потом рассказываем, что выяснили, и решаем дальше. Это и обязательство, и защита от бесконечного исследования.

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

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

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

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

Обратная сторона правила: оценивать нужно, когда от числа зависит выбор. Что берём в спринт из двух вариантов; успеваем ли к обязательству перед партнёром; стоит ли функция своей цены. Проверочный вопрос перед встречей: какое решение мы примем по-другому, если число окажется вдвое больше? Нет ответа — оценка не нужна.

Частые ошибки

Points превращают в часы. «5 points — это же примерно день, да?» Стоит завести такую таблицу перевода — и весь смысл относительной оценки исчезает. Points снова становятся временем, со всеми его проблемами. Points остаются points: их не переводят в часы, ими только сравнивают задачи между собой.

Velocity используют как метрику продуктивности. «В прошлом спринте 20, в этом 18 — стали хуже работать?» Нет. Velocity зависит от того, какие задачи попались и как их оценили. Команду легко «мотивировать» — она начнёт завышать оценки, и velocity красиво вырастет, хотя работы сделано столько же. Число будет расти, польза — падать. Как только velocity становится целью, она перестаёт быть честным измерением — это закон Гудхарта: любая метрика, ставшая целью, портится.

Velocity сравнивают между командами. «У той команды velocity 40, у нас 20 — они вдвое быстрее». Это бессмыслица: points у каждой команды свои, эталоны разные. Сравнивать их velocity — как сравнивать рост в разных, неизвестных единицах. Velocity имеет смысл только внутри одной команды и только во времени.

Оценки незаметно раздуваются со временем. Это та же механика, что при давлении сверху, но происходит она сама собой, без чьего-либо умысла. Эталон — «небольшая понятная задача на 2 points» — живёт в памяти команды, а память смещается: после нескольких неприятных сюрпризов похожая задача получает уже 3, потом 5. Через год пятёрка означает то, что год назад означало тройкой, и velocity выросла с 20 до 26 без роста сделанной работы.

Чем это плохо: прогноз остаётся верным (points и скорость раздулись согласованно), а вот сравнение во времени ломается. «Мы стали быстрее на треть» — неправда, и решения, принятые на этом основании, тоже.

Как замечают и лечат:

• Держат эталон снаружи памяти. Пара-тройка конкретных закрытых задач с их оценками записана и лежит рядом с доской. Сравнивают с ними, а не с ощущением.
• Раз в квартал перепроверяют эталон. Берут три-четыре задачи, закрытые давно, и оценивают заново, не глядя на прежние числа. Систематический сдвиг вверх виден сразу.
• Смотрят на счёт задач рядом с points. Число закрытых строк бэклога инфляции не подвержено. Points растут, а штук столько же — значит, выросли оценки, а не команда.
• Не перерасчитывают историю. Обнаружив сдвиг, эталон просто фиксируют заново и договариваются, что сравнение velocity «до» и «после» не имеет смысла. Пересчёт прошлых спринтов — работа впустую.

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

Альтернатива вместо ошибки: #NoEstimates

Есть и радикальная альтернатива — подход #NoEstimates. Его идея: если задачи в backlog разбиты на достаточно мелкие и примерно однородные, можно вообще не оценивать их в points, а просто считать количество завершённых задач за период. Разбитые до сравнимого размера штуки закрываются с похожей скоростью, поэтому счёт задач даёт прогноз не хуже velocity, но без ритуала оценки. Подход не универсален — он требует дисциплины в дроблении задач, — но полезен как напоминание: оценка не самоцель, а средство. Если счёт задач отвечает на вопрос «когда успеем», сложная оценка может быть и не нужна.

Коротко

• Оценка в часах обманчива: время зависит от исполнителя, скрытых деталей и перерывов; сравнивать задачи мы умеем лучше, чем измерять их. Story points оценивают величину задачи (объём, сложность, риск) относительно эталонной, а не время; растущий шаг шкалы (ряд Фибоначчи) отражает падение точности на крупных задачах.
• Planning Poker — тайная одновременная оценка всей командой; ценность в расхождениях, которые вскрывают разное понимание задачи и риски. Velocity — сумма points, закрытых за спринт; по среднему за несколько спринтов считают вилку прогноза («от 4,5 до 5,6 спринта»), а не дату.
• Velocity — прогноз для самой команды, а не оценка её работы сверху: как только её требуют «повышать», оценки раздувают и число теряет смысл.
• Points не переводят в часы, velocity не сравнивают между командами; а если задачи разбиты мелко и однородно, вместо points можно просто считать их количество (#NoEstimates).
• Оценивают строку бэклога с понятным результатом: кто, что и зачем плюс критерии приёмки «дано — когда — тогда»; строка без критериев не оценивается, а возвращается на уточнение.
• Мощность на спринт — поправка к среднему: отпуска, праздники, дежурство и обещанная работа вне спринта вычитаются из доступного времени, и планировать на сто процентов означает планировать срыв.
• На «нам всё равно нужна дата» отвечают датой с вероятностью, заранее договорённым планом на случай отставания и недельным обновлением прогноза; самое сильное предложение — дату фиксируем, объём делаем управляемым.
• Оценки раздуваются сами собой: эталон в памяти смещается, скорость растёт без роста работы; держат записанный эталон, перепроверяют его раз в квартал и смотрят рядом счёт задач.
• Кроме points есть размеры футболок для грубой прикидки и счёт задач за период, он же пропускная способность потока — это и есть #NoEstimates, та же мера в штуках вместо баллов.
• Не оценивают исследование (вместо оценки ограничение по времени), очевидную мелочь, неизбежную работу и далёкий конец очереди; проверочный вопрос — какое решение изменится, если число окажется вдвое больше.

Что почитать дальше

• Scrum — спринты, роли и ритуалы, в которых живут оценка и velocity.
• Kanban — поток без спринтов, где вместо velocity смотрят на пропускную способность и время прохождения.
• Extreme Programming — практики, которые режут задачи до мелких и однородных: с ними счёт задач работает вместо оценки.
• Масштабирование Agile — что делать, когда команд много, а points у каждой свои.