Что такое story points
Story points, или стори поинты, — единица, в которой оценивают размер задачи относительно других задач. Само по себе число ничего не говорит о часах и днях. История на 5 поинтов для команды примерно в два с половиной раза крупнее истории на 2 и заметно меньше истории на 8. Вся польза стори поинтов вытекает из этого сравнения, и благодаря ему они стали одной из самых распространённых единиц для оценки задач в Scrum- и XP-командах.
Что измеряют стори поинты
В одной оценке смешано несколько вещей:
- Объём работы. Форма на двадцать полей делается дольше, чем на два.
- Сложность. Хитрый алгоритм или капризная интеграция могут занимать мало строк кода и при этом требовать много размышлений.
- Неопределённость, то есть сколько вы ещё не знаете. Незнакомое API, размытые требования или модуль, в который никто не заглядывал годами, делают историю рискованнее, а рискованная история получает оценку побольше.
Отдельно эти составляющие никто не считает и не складывает. Человек взвешивает их в голове и выбирает карту, поэтому двое разработчиков могут поставить одинаковую восьмёрку по разным причинам. Один видит много рутинной работы, другой видит рискованную миграцию базы. Когда причины настолько разные, их стоит коротко обсудить, и покер планирования устроен как раз так, чтобы такой разговор случался.
Почему не в часах
Часы кажутся понятнее, особенно людям вне команды. У оценки в часах есть несколько проблем, которых относительные размеры избегают.
Люди гораздо лучше сравнивают, чем измеряют. Спросите, какой высоты дом напротив, и человек задумается. Спросите, выше ли он соседнего, и ответ будет сразу. С задачами так же: на вопрос «эта задача больше, чем форма входа?» ответить проще, чем на «сколько часов это займёт?», и ответы у разных людей ближе друг к другу.
Часы зависят от исполнителя. Сеньор, который сам писал модуль оплаты, сделает правку за три часа, новичку на ту же правку понадобятся два дня. Стори поинты описывают саму работу, поэтому вся команда может договориться об одном числе, кто бы задачу потом ни взял.
Оценка в часах быстро превращается в обязательство. Если в задаче написано «12 часов», это начинают воспринимать как срок, а тот, кто не уложился, чувствует себя виноватым. Оценку в поинтах проще воспринимать как размер, и о рисках с ней говорить свободнее.
Наконец, в часах обычно не учтено всё, что не код: ревью, созвоны, ожидание другой команды, починка падающего CI. Velocity в поинтах всё это уже включает, потому что считается по тому, что команда на самом деле закрыла.
Эталонная задача
Для относительной оценки нужно, с чем сравнивать. Перед первой сессией выберите одну-две задачи, которые команда уже сделала и хорошо помнит, и договоритесь об их оценке.
Например, небольшая понятная задача вроде «добавить сортировку по дате в список заказов» пусть будет двойкой. Потом найдите задачу покрупнее, скажем выгрузку списка заказов в Excel с фильтром по датам, и договоритесь, что это примерно 5. Дальше каждую новую историю сравнивают с этими двумя. Больше, чем сортировка? Примерно как выгрузка?
Запишите эталонные задачи там, где команда их видит: в начале бэклога или в закрепе командного чата. Через несколько месяцев шкала поселится в головах, но новичкам примеры всё равно понадобятся.
Velocity: для чего нужны стори поинты
Velocity (скорость команды) — сумма стори поинтов, которые команда закрыла за спринт. Если закрыты истории на 3, 5, 8, 1 и 5, velocity спринта равна 22. История, готовая на 90 % к концу спринта, в velocity не попадает. Это кажется жёстким, зато числа остаются честными.
По одному спринту почти ничего не понятно. Через три-четыре спринта появляется диапазон, например от 20 до 26, и планируют уже по нему. Он подсказывает команде, сколько брать в следующий спринт, а владельцу продукта помогает прикинуть сроки. Если до релиза в бэклоге 110 поинтов, а velocity около 22, впереди примерно пять спринтов.
Если состав команды и характер работы более-менее стабильны, velocity обычно выравнивается за несколько спринтов. Отдельные оценки ошибаются в обе стороны: одни пятёрки оказываются тройками, другие восьмёрками, и за спринт многие ошибки взаимно гасятся. Velocity не устоится, если команда часто меняется, если спринт съедают внеплановые задачи или если шкала незаметно уплывает.
Как velocity используют на груминге и планировании спринта, описано на странице про scrum poker.
Мифы, из-за которых начинаются проблемы
«Один поинт равен одному дню»
Рано или поздно кто-то захочет перевести поинты в часы. Как только поинт стал равен фиксированному числу часов, вы снова оцениваете в часах, только с лишним шагом пересчёта и со всеми проблемами, описанными выше. Если нужна дата, прогнозируйте в спринтах по velocity.
«Команды можно сравнивать по velocity»
У команды А velocity 40, у команды Б 20. Напрашивается вывод, что А работает вдвое продуктивнее, и он неверен. У каждой команды свои эталонные задачи и своя шкала, и пятёрка команды А может оказаться двойкой команды Б. Когда руководство всё равно сравнивает velocity разных команд, команды начинают завышать оценки. Velocity растёт, результат не меняется, и для планирования числа больше не годятся.
«Чем выше velocity, тем лучше»
Стабильная velocity полезнее растущей, потому что по ней можно строить надёжные прогнозы. Если velocity резко подскочила, прежде чем радоваться, проверьте, не поплыла ли шкала.
«У каждой истории должно быть точное число»
Стори поинты намеренно грубые. Большинство команд пользуется шкалой Фибоначчи, где промежутки растут вместе с числами. Спорить, 13 это или 14, не приходится, потому что выбирать нужно между 13 и 20.
С чего начать
Если команда никогда не оценивала задачи в стори поинтах, начать можно так:
- Договоритесь об одной маленькой и одной средней эталонной задаче, как описано выше.
- Возьмите стандартную колоду: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?» и ☕.
- На одной встрече оцените верх бэклога покером планирования, чтобы никто не задал якорь остальным. Хватит бесплатной онлайн-комнаты без регистрации. Историй на два спринта вполне достаточно, оценивать весь бэклог незачем.
- Первые несколько спринтов не гонитесь за точностью: шкале нужно время, чтобы устояться.
- Сначала просто записывайте velocity и опирайтесь на неё в планировании, когда появится устойчивый диапазон.
- Через пару месяцев вернитесь к эталонным задачам. Если в команде всё чаще звучит «это больше нашей старой пятёрки», пересоберите шкалу.
Первые оценки будут промахиваться, иногда сильно, и эти промахи полезны. Когда тройка превратилась в неделю работы, разберите на ретроспективе, почему так вышло, и следующая похожая история получит оценку точнее.