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

Но почему столько хейта? Неужели всё действительно так плохо? Или дело не в Story Points, а в том, как именно их используют?

Меня зовут Семён, я тимлид в МТС Аналитике, бывший Java-разработчик, сертифицированный Scrum Master и преподаватель курса по Java в МФТИ. Веду блог. За годы работы много раз видел, как команды мучаются с оценками задач.

В этой статье расскажу, за что критикуют оценки, чем отличаются человеко-часы от футболок и Story Points, когда их стоит применять — а когда лучше не мучиться и попробовать NoEstimates. И почему отношение к Story Points столь неоднозначно.​

Будет и про типовые ошибки, и про работающие подходы — чтобы планировать задачи без лишней боли. Спойлер: идеального способа оценки задач не существует. Зато есть вполне рабочие способы не сойти с ума и при этом нормально планировать работу.

Главное заблуждение проектного менеджмента

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

По началу меня это жутко фрустрировало. Я не понимал, в чём причина. Но чем больше работал, общался с людьми и смотрел на разные проекты, тем чаще закрадывалась мысль: это нормально и по-другому быть не может. Проекты всегда уезжают по срокам. Вопрос только — почему?

В книге Нассима Талеба «чёрным лебедем» называют событие, которое почти невозможно предсказать. Либо вы вообще не предполагаете, что такое может случиться, либо шанс настолько микроскопический, что о нём даже не думаешь. А когда это всё-таки происходит, то имеет разрушительные последствия для настоящего и будущего времени и тогда появляется рациональное обоснование.

Вот примеры «чёрных лебедей» из жизни IT:

• Ведущий разработчик слёг на месяц на больничный

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

• Задача «вроде изян» оказалась намного сложнее

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

• Два месяца делали аналитику, но задача стала вдруг неприоритетной

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

• Новые требования от топ-менеджмента или регуляторов

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

Это реальность любой IT-команды. Нет смысла пытаться всё учесть заранее. Главное — понимать, что подобные вещи случаются, и, к сожалению, полностью предсказать их невозможно.

Следствия заблуждения

Допустим, произошла неприятная ситуация — проект сдвинулся по срокам. У нас есть убеждение, что проект сдвигаться не должен, это неправильно. Тогда начинаем искать «идеальный» инструмент оценки задач. Что-то мы, видимо, не так считали — сейчас найдём правильный подход, пересчитаем — и всё будет хорошо. Но такого инструмента не находим, потому что, забегая вперед, его не существует и не может существовать.

Из этого рождается порочный цикл (или классическая ловушка):

1. Проект сдвинулся по срокам

2. Ищем «идеальный» способ оценки

3. Возвращаемся к пункту №1

Фрустрация нарастает, команды недовольны, мы — тоже. Начинаем думать, что люди какие-то не такие, или вообще всё не так, надо сменить компанию, проект, всех уволить, набрать заново. Выход — выйти из этого цикла и посмотреть на ситуацию шире.

Важный вывод по способам оценки, которые мы будем обсуждать:

Все способы оценки задач без исключения, даже человеко-часы, носят субъективный и вероятностный характер. Чем больше длительность и объём проекта, тем сложнее гарантировать точность оценок.

Тот, кто говорит, что есть способ оценки, который всегда на 100% правильный. И благодаря которому у вас никогда проект не сдвинется по срокам, вас обманывает. Имейте это в виду.

Зачем оценивать задачи

Хорошо, мы поняли, что способы оценки субъективны и несовершенны, а проекты всегда сдвигаются по срокам. А зачем мы тогда вообще оцениваем задачи, если всё так плохо и мы не можем ничего гарантировать на 100%?

Ответ прост: чтобы управлять рисками и ожиданиями.

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

В этом ценность. Не в том, чтобы угадать срок с точностью до дня или часа. А в том, чтобы быть готовыми обсуждать риски и корректировать ожидания. Если благодаря оценке вы заранее проговорили вероятные сценарии, значит, она была полезной.

Критерии выбора оценки задач

• Трудоёмкость процесса оценки: придётся валидировать

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

• Масштабирование оценки между командами

Можем ли мы масштабировать оценку между другими командами? Забегая вперёд — не все оценки это позволяют.

• Точность оценки

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

Оценка в человеко-часах/днях

Для визуализации оценки в человеко-часах или днях удобно использовать диаграмму Ганта, где слева — список задач, сверху — таймлайн. Сначала идёт задача 1, потом задача 2, какие-то задачи выполняются параллельно, какие-то последовательно.

Плюсы оценки в человеко-часах:

1. Масштабируемость, потому что время — универсальная единица измерения 

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

2. Легко разъяснить руководству

Руководитель спрашивает: «Сколько ещё нужно времени?» — «Мы оценили условно в 8 часов, осталось ещё 4», — понятно и прозрачно.

Конечно же есть минусы:

1. Очень трудоёмкий процесс

Главный минус в том, что процесс оценки, сколько времени в часах или в днях займёт задача — очень трудоёмкий.

Рассмотрим на примере. Состав моей команды — 15 человек:

• 3 бэкенд-инженера

• 3 фронтенд-инженера

• 2 дата-инженера

• 2 QA-инженера

• 3 аналитика

• 1 UX-писатель

• 1 UI-дизайнер

Предположим, нам нужно оценить какую-то story в человеко-часах. Story — это такой запрос от бизнеса, в котором участвует сразу несколько компетенций.

В story предполагается задействовать фронтенд-, бэкенд- и дата-инженеров. Возьмём сценарий, когда DoR (Definition of Ready) закрыт, уже есть БТ, ТЗ, макеты и пр. DoD (Definition of Done) тоже чётко сформулирован и понятен. Такое в реальности бывает редко, но тут идеальная story в вакууме.

Чтобы оценить всего одну story в человеко-часах, нужно:

• Собрать всех представителей компетенций (хотя бы по одному человеку от каждой). В идеале — всю команду.

• Прописать зависимости, потому что работать параллельно все не смогут.

Например: фронтендеры ждут, пока сделают бэкенд, бэкендеры ждут дата-инженера, а он ждёт, пока кто-то из другой команды обработает внешнюю заявку.

• Оценить работу каждой компетенции в часах или днях.

Ещё один минус:

2. Не учитываются изменения скоупа, что в мире IT возникает часто.

Вы Team Lead или Project Manager. Вместе с командой сели и оценили story в человеко-часах. Потратив на это время, пришли к продакту и говорите: «Смотри, бизнес-запрос, который ты прислала, займёт у нас Х времени команды. Мы успеваем (или не успеваем) в наш спринт». Продакт говорит: «Хорошо, я тебя поняла, но я пересмотрела условия, в таком виде задача для бизнеса не очень полезна. Давай добавим вот этот пункт, и тогда всё будет идеально». Но человеко-часы уже посчитаны. Диаграмма Ганта нарисована. Всё расписано по часам. Вы говорите: «Хорошо, я сейчас ещё пообщаюсь со своей командой, ещё раз оценю и вернусь».

3. Люди приравниваются к часам/дням: не все работы параллелятся

Если вы в первый раз потратили на оценку много времени, потом во второй раз  — ещё столько же. Можно представить, сколько времени уйдёт на это вместо того, чтобы заниматься основными задачами. Есть известный мем о том, что девять женщин за один месяц ребёнка не родят. Но если задача занимает три человеко-дня, и у нас три человека в команде, то с точки зрения математики за один день мы должны управиться. Понятно, что не всегда, потому что не все задачи можно распараллелить. В каких-то ситуациях это действительно может сработать, но чаще всё-таки нет.

Где хорошо применима оценка в человеко-часах/днях

Я много говорил про минусы оценки в человеко-часах или днях — тут неудобно, там не сработает, здесь не очень хорошо. Но если бы этот подход был совсем бесполезным, он бы нигде не прижился. Значит, есть сценарии, где такая оценка работает хорошо. Ответ очевидный — это waterfall.

Классический waterfall в IT уже встречается редко. Но если вы строите склад или самолёт, оценка в человеко-часах вполне оправдана, так как:

• Приоритеты не меняются

Вряд ли посреди строительства самолёта заказчик вдруг захочет, чтобы это был не пассажирский самолёт, а истребитель. Или вообще вертолёт. А вот в IT такое происходит регулярно.

• Скоуп остаётся прежним

Если вы решили, что в самолете 200 мест, то 200 мест в нём и будет. К вам не придёт заказчик под конец проекта и не скажет: «А давай ещё 50 мест поставим». Потому, что все понимают: чтобы это сделать, надо переделывать всё с нуля.

• Сроки не двигаются

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

Поскольку оценка в человеко-часах для нас не сильно актуальна, перейдём к более распространённым практикам в мире IT.

Оценка в футболках

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

Когда мы оценивали задачу в человеко-часах, процесс выглядел так. Есть story, которая разбивалась на компетенции: бэкенд, фронтенд, дата-инженеры. Мы смотрели на задачу снизу вверх: раскладывали на отдельные части и пытались оценить каждую часть в человеко-часах. Могли что-то заложить на коммуникации — допустим, один рабочий день на уточнения и обсуждения. Потом всё складывали и получали итоговую оценку.

Это долгий, трудоёмкий процесс с сомнительной точностью.

При оценке задач в футболках принцип совсем другой. Мы смотрим на задачу сверху вниз и не дробим её на мелкие части. Представляем, что это какая-то абстракция, как интерфейс на языке Java и присваиваем условный размер — S, M, L или XL. А размер оцениваем по истории тех задач, которые делали раньше.

Допустим, мы уже закрыли задачи 1, 2 и 3. Теперь смотрим на задачи 4, 5 и 6 — и сравниваем их с предыдущими.

Вместе с командой вы, как правило, уже знаете, сколько времени ушло на старые задачи, какой по ним был скоуп, были ли какие-то неожиданности. И дальше рассуждаете так:

• Задача 1 была M. Задача 4 на неё похожа, значит, тоже M.

• Задача 2 была L — задача 5 тоже примерно L.

• И так далее.

Выводы по оценке задач в футболках

→ Размер (S, M, L, XL) присваиваем всей story целиком.

Мы не присваиваем футболки отдельным подзадачам или компетенциям. Не бывает так, что дата-инженер здесь тратит M, а backend — L. Бизнес-запрос оцениваем как единое целое. Это одна story, и она на L — от начала и до конца.

→ Размер — это не время выполнения, а субъективная оценка.

Это важно. Нельзя сказать, что L — это столько-то часов, а M — это столько-то человеко-часов. Этот вопрос вообще не имеет смысла. Всё, что мы знаем — это что M сложнее, чем S, но проще, чем L. Вероятно, M займёт больше времени, чем S, и меньше, чем L. Но конкретное число часов или дней на решение задачи не называем.

→ Не переводим в человеко-часы.

Как только команды начинают использовать футболки, возникает соблазн прикинуть, сколько это человеко-часов. Но это разные способы оценки задач. Футболки — это относительная оценка, субъективная попытка прикинуть совокупность всех работ в рамках story и выразить её в условной единице. Поэтому не стоит пытаться переводить её обратно в человеко-часы.

Плюсы оценки в футболках

1. Легко внедрить: с минимальными усилиями можно начать оценивать задачи в футболках хоть прямо сейчас.

2. Простой и быстрый процесс оценки. Вы спрашиваете: «Как думаешь, сколько это в футболках? Выбери одну из четырёх». И человек что-то называет.

3. Можно масштабировать на квартальные эпики. Про этот важный плюс я скажу ниже — он заслуживает отдельного разговора.

Минусы оценки в футболках

1. Сложно оценить capacity команды

Допустим, в спринте № 19 вы закрыли две задачи размера L и три задачи размера M. Начинается спринт № 20, и у вас в плане четыре задачи, каждая из которых имеет оценку L. Возникает вопрос: можно сказать, что 3M = 2L? Если да — то вроде бы можно брать все четыре задачи. Если нет — наверное, стоит взять только три.

Но вывести универсальную математическую формулу здесь не получится. Потому что оценка, как мы уже обсуждали, субъективная. Плюс задачи одного размера — даже если все они M — могут в реальности занимать разное время. Поэтому ответ на вопрос дать трудно, всё познается с опытом.

2. Больше подходит для оценки квартала, а не спринта

Оценка в футболках лучше работает для масштабных вещей — например, для квартальных эпиков, чем для оценки конкретных story. Она не обладает достаточной степенью гранулярности — слишком обобщённая и широкая. А story — это конкретный бизнес-запрос, который вы хотите сделать здесь и сейчас, в ограниченное время, с чёткими границами. И здесь футболка мало о чём говорит.

Исходя из этой проблемы, переходим к следующему способу оценки — Story Points.

Оценка в Story Points

Принцип работы Story Points покажу на примере.

У нас уже есть знакомые футболки — S, M, L и XL. Попробуем разбить их на более мелкие части. Например:

• S — это XXS, XS, S

• M — это M, XM

• и так далее.

Получается восемь разных элементов для оценки задач. Но использовать их в таком виде бессмысленно. Потому что если мы оцениваем задачи настолько мелко, потом вообще непонятно, как считать capacity команды. Например, если вы закрыли 5 XS или 8 L, неясно, как потом это суммировать.

Чтобы решить проблему, мы каждой футболке присваиваем число, и используем для этого числа Фибоначчи. Это значит, что каждая следующая задача по сложности примерно равна двум предыдущим. Эти числа и есть Story Points.

То есть:

• мы разбили футболки на более мелкие части,

• присвоили каждой части число,

• и эти числа называем Story Points.

Выводы про Story Points:

→ Story Points, как и футболки, такая же субъективная и относительная оценка, несмотря на то, что в ней используются числа. Это просто удобный способ сравнивать задачи между собой.

→ Воспринимайте Story Points как более гранулярную версию футболок. Я люблю говорить, что Story Points — это футболки на стероидах. 

→ При оценке задачи в Story Points учитываем всё, что может повлиять на выполнение задачи: работу нескольких компетенций, учитываем возможные встречи, риски, простои и так далее.

Плюсы оценки в Story Points

1. Легко оценивать capacity команды

Чтобы понять, сколько мы можем закрыть задач, нужно просто сложить все Story Points, которые закрыли за прошлый спринт (лучше, чтобы таких спринтов было несколько), вывести среднее значение и в следующем спринте сделать предположение.

Например, если мы в среднем закрываем 40 Story Points (SP) за спринт, то дальше можем прикинуть: взяли задачи на новый спринт — получилось 50 SP. Скорее всего, всё сделать не успеем. А если остались в рамках 40 SP — вероятность уложиться намного выше.

2. Легко менять скоуп спринта

Если бизнес говорит: «Срочно возьми этот запрос прямо сейчас, он суперважный», а задача у нас уже оценена в Story Points — всё, что остаётся сделать, это убрать из спринта другую задачу с примерно таким же количеством SP. Так вы сохраняете общий объём работы в комфортных для команды рамках — те же 40 или 50 SP, сколько обычно получается.

3. Оценка точнее футболок

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

Конечно, у Story Points есть минусы, про них поговорим дальше, но предварительно обсудим анти-паттерны — как точно не надо использовать Story Points.

Анти-паттерны в работе со Story Points

Когда команды используют Story Points неправильно, они ловят фрустрацию и делают вывод, что это плохой подход и отказываются от него совсем. Но проблема обычно не в Story Points, а в ошибках по пути.

Анти-паттерн №1 

«А давайте мерить производительность команды по количеству Story Points!»

Story Points — это числа. Их хочется сравнивать, складывать, анализировать. Появляется соблазн сделать из них KPI: чем больше Story Points приносит команда, тем она эффективнее.

Допустим, есть команда, которая в одном спринте закрыла две задачи: одна на 8 SP, другая на 13 SP. В сумме — 21 SP. Приходит менеджмент и говорит: «Ребят, новые вводные — чем больше Story Points вы приносите, тем лучше. Это ваша метрика эффективности, KPI. Впишем в ваши показатели премирования минимум Х Story Points». Команда говорит: «Хорошо, никаких вопросов. Теперь у нас 42 Story Points». Руководитель смотрит — ого, в два раза производительность выросла!

Но в реальности команда как закрывала две задачи похожего размера, так и закрывает. Производительность осталась той же. Просто была шкала, где задачи оценивали в 8 и 13. Сказали приносить больше Story Points — хорошо, вот вам 16 и 26.

Потому что команда — как джинн из сказки: выполняет не то, что вы хотите, а то, что вы просите. Попросили больше Story Points — получите. Поэтому будьте аккуратны в своих желаниях.

Story Points — это относительная оценка внутри конкретной команды. Абсолютные значения мало что скажут.

Внутри команды люди понимают: «Задача на 5 SP — это вот такая штука, задача на 10 SP — вот такая». А для человека извне эти числа ничего не значат. Он не знает, какая у этой команды шкала и как они меряют. Поэтому если у вас появится идея использовать Story Points как KPI или сравнивать команды между собой по количеству Story Points — это на ваш страх и риск.

Анти-паттерн №2

«А давайте сконвертируем Story Points в человеко-часы!»

Это более популярный анти-паттерн. 

Story Points — это футболки. Футболки конвертировать в человеко-часы не имеет смысла. Но всё-таки почему нельзя? Вроде бы тут числа, и там числа. Рассмотрим два варианта, как люди обычно пытаются это сделать.

1. Универсальная конвертация

Мы вывели общую формулу и говорим, что для всех команд в нашей компании или в нашем продукте 1 SP равен X часам.

2. Индивидуальная конвертация 

Этот вариант кажется более гибким. Мы приходим к каждой команде отдельно, общаемся и выводим для них формулу. Например, 1 SP для одной команды равен Y часам, для другой — Z.

При универсальной конвертации команды начнут завышать оценки. Всё как в анти-паттерне №1. Люди захотят выбить для себя как можно больше времени, чтобы снизить риски, чтобы с них же потом не спросили. Поэтому на самые простые запросы они будут говорить, что это 100–200 SP — сколько угодно, чтобы заложить больше времени.

В случае индивидуальной конвертации способов для манипуляции меньше, потому что вы с каждой командой работаете по отдельности. Но и тут возникают проблемы.

Допустим, мы договорились с командой, что их задача на 5 SP — это, скажем, 20 часов работы. А дальше вопрос: а как эти 20 часов распределить между бэкендом, фронтендом и дата-инженерами, которые вместе над этой задачей работали? Поровну делим или какие-то коэффициенты для них придумаем?

Самая неприятная мысль, что разные задачи с одним и тем же количеством Story Points могут выполняться разное время, особенно если компетенции отличаются. Это нормально. Story Points — это оценка субъективной сложности задачи, а не времени её выполнения. Поэтому эти конвертации могут привести не туда.

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

Анти-паттерн №3

«Я босс, и я говорю вам, что эта задача должна занять 20 SP!»

Этот анти-паттерн уже не столько про Story Points, сколько вообще про подход к проектному менеджменту.

Классическая ситуация: приходит босс. Команда говорит: «Эта задача на 30 SP. В спринт не влезает». А босс в ответ: «Нет, ребят, я уже всем пообещал, договорился. Пусть будет 20 SP. И тогда точно влезет в спринт. Всё, удачи!».

Конечно, так делать нельзя, потому что оценивать задачи должны не руководители, а исполнители. Story Points — это субъективная оценка команды. Её невозможно навязать сверху.

Команда сравнивает новую задачу с теми, которые делала раньше, и на основе этого говорит свою оценку в SP. Это их инструмент для планирования и расчёта capacity.

Если вы говорите, что это не 30, а 20, то вы, по сути, обнуляете весь их опыт и все старания. Как руководитель, вы не знаете всех тонкостей работы.

Вот я, например, был и остаюсь Java-разработчиком. Теоретически могу оценить работу других Java-разработчиков или бекэндеров. Но у меня в команде есть фронтендеры, аналитики, веб-дизайнеры, дата-инженеры. Оценить время работы этих компетенций мне будет гораздо сложнее.

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

Теперь, думаю, стало понятнее, где и зачем имеет смысл использовать Story Points. Дальше поговорим о том, какие у них проблемы.

Минусы Story Points

1. Не масштабируются между командами

Story Points работают только внутри конкретной команды. Как только вы выходите вовне — в другую команду или проект — лучше вообще про Story Points не говорить. Есть риск, что вас начнут по ним сравнивать или даже мерить эффективность.

2. Неприменимы к задачам больше, чем story

Story Points подходят только для оценки story. Оценить квартальный эпик ими не получится. Просто потому, что для такой оценки нужна детальная информация: готовый DoD, аналитика, чёткое понимание, что именно вы собираетесь делать. А в эпиках этого обычно нет. Там и DoD размытый, и скоуп непонятный. Оценить в Story Points довольно сложно, зато очень легко — в футболках.

3. Покер-планинг может занимать много времени

Я покер-планинг здесь не упоминал, но по моему опыту, если вы только начинаете внедрять Story Points, то этот процесс может занять много времени, особенно в большой команде. Это тоже нужно учесть.

4. Не учитывается индивидуальная загрузка компетенций

И у Story Points, и у футболок есть общая проблема — они показывают загрузку команды в целом, но не показывают, кто из специалистов реально насколько загружен.

Мы смотрим на story, видим capacity команды, но можем потерять нить: сколько времени занят бэкендер, фронтендер, дата-инженер и так далее. Кто-то из них может работать на износ, кто-то, наоборот, чилить или вообще ничего не делать.

Универсального решения здесь нет. Могу порекомендовать только брать в спринт чуть больше задач, чем ожидаемое capacity. Таким образом, если кто-то закончил раньше, он сможет взять резервную задачу и работать над ней.

Когда Story Points стоит внедрять?

Не обязательно, чтобы выполнялись все условия, о которых я сейчас расскажу. Но если хотя бы часть из них про вас — возможно, Story Points вам подойдут.

Небольшая Scrum-команда (до 10 человек)

Если в команде 15 или 20 человек, покер-планинг будет занимать слишком много времени. Все голосуют закрыто, у кого-то обязательно разойдутся оценки, команда начнёт это обсуждать, выяснять, спорить — и процесс затянется.

В небольшой группе до 10 человек этот инструмент использовать удобней.

Скоуп спринта часто меняется

Если вам регулярно прилетают запросы типа: «Возьми вот это срочно», «Убери вот это», «Добавь то» — Story Points отлично помогут. Вы быстро смотрите на текущий спринт и понимаете: «Окей, добавляю новую задачу на 8 SP — значит, надо убрать что-то на те же 8 SP». Не нужно долго гадать.

Процесс PBR (Product Backlog Refinement)/grooming нормализован

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

Когда вы приходите на планирование, у вас уже должен быть пул оценённых задач, в которых проставлены Story Points. Вы смотрите на среднее capacity и спокойно набираете задачи в спринт. А вот если такого процесса нет, и вы приходите на планирование с пустым бэклогом — Story Points не сильно помогут.

Команда в стадии Norming или выше

В теории командного развития четыре стадии:

1. Forming — команда формируется, люди притираются друг к другу.

2. Storming — появляются первые конфликты, люди пытаются понять, кто авторитет, кого стоит слушать, а кого нет.

3. Norming — конфликты начинают урегулироваться, команда повышает свою производительность.

4. Performing — состояние потока для команды. На этой стадии команда обычно не задерживается надолго. Она начинает расформировываться, либо приходит кто-то новый и вновь начинается Norming.

Story Points плохо приживаются, если команда только на стадии Forming или Storming. Люди ещё не привыкли друг к другу, не понимают процессов. Скорее всего, вы столкнётесь с большим сопротивлением при попытках внедрить Story Points.

Тимлид/scrum master, а также PO понимают смысл

Самое главное — вы как тимлид (Project Manager, Scrum Master, Product Manager) должны понимать смысл подхода. Если руководитель не понимает и искренне считает, что привлечь человеко-часы или устраивать соревнования, кто закрыл больше Story Points — нормально, есть риск скатиться в один из анти-паттернов и получить кучу недовольства от команды и заказчиков. Такой подход действительно ничего хорошего не принесёт.

Общие советы по внедрению Story Points

• Начните с футболок

Если вы раньше не работали со Story Points, не стоит сразу прыгать с места в карьер. Попробуйте использовать футболки — их легко внедрить и объяснить команде. Если увидите в этом какой-то профит, можете попробовать сделать шаг в сторону Story Points.

• Не усредняйте оценки вовремя покер-планинга

Известная ошибка, когда кто-то из команды проголосовал за 8 SP, кто-то за 13 SP — и мы считаем 11 SP. Это неправильно. Если люди называют разные оценки, они по-разному видят задачу и воспринимают её сложность. Это потенциальное место для дискуссии, нужно его разрулить и прийти к общему знаменателю.

• Не меняйте оценки постфактум

• Не дробите частично закрытые story по количеству Story Points

Вы запланировали задачу на 20 SP. Но за спринт полностью закрыть не успели. Сделали бэкенд, остался фронтенд. И возникает соблазн засчитать 10 SP как выполненную половину, а вторую — отрубить. Не надо так делать, тем самым вы нарушите свою же статистику. Если указали 20 SP, так и оставляйте.

• Записывайте всё

Важно фиксировать все данные по Story Points — от итерации к итерации. Если вы работаете в Jira или аналогичной системе — используйте плагины или встроенные инструменты, которые будут считать, сколько Story Points вы реально закрываете за спринт. Так вы будете видеть динамику. В какой-то момент команда выйдет на плато — например, 40 или 50 SP за спринт.

Альтернатива — NoEstimates

Напомню, что оценивать задачи, вообще-то, не обязательная практика. Есть альтернативный способ — NoEstimates, то есть «никаких оценок».

Идея проста. Если итерация достаточно маленькая, оценка не нужна, потому что вы и так видите capacity команды. 

Предположим, что ваш спринт длится неделю. За это время вы не сможете сделать колоссальное количество работы. Вы и так понимаете, сколько задач реально закроете за это время. Поэтому ни Story Points, ни футболки вам здесь в теории не потребуются.

Чем меньше дистанция, тем ниже вероятность ошибиться в оценке.

Когда вас просят оценить задачу на три месяца — это история, где вероятность ошибки велика. А когда задача занимает пару дней — это совсем другое дело.

Для внедрения NoEstimates нужно, чтобы задачи были достаточно гранулярны и закрывались за короткую итерацию. Если у вас такого пока нет (например, у нас в команде это не так — и поэтому мы NoEstimates не используем, хотя подход мне очень нравится), то начать стоит с другого. Сначала — научиться так декомпозировать задачи, чтобы они укладывались в маленькие итерации. А уже потом — пробовать внедрять NoEstimates.

Выводы

Любая оценка задач несовершенна. Поэтому самое главное в проектном менеджменте — это не столько сама оценка, сколько управление рисками и ожиданиями.

Capacity есть у любой команды. И оценка нужна не для того, чтобы «втиснуть» команду в нужное количество Story Points, а чтобы измерить это capacity и чуть точнее планировать следующие итерации.

Story Points — это те же самые футболки, только выраженные в числах. Кроме того, это в первую очередь инструмент самой команды. Не для руководителя. Не для заказчика. А для команды — чтобы ей было проще управлять ожиданиями других людей — заказчиков, стейкхолдеров, менеджеров.

Хорошая практика — брать в спринт чуть больше задач, чем ваша средняя capacity. Это поможет избежать ситуации, когда кто-то из специалистов простаивает без работы. Потому что, как мы обсуждали раньше, футболки и Story Points оценивают задачу целиком — с учётом всех компетенций в команде.

И главное: Story Points — это хороший инструмент, но не обязательный. Иногда вам будет достаточно футболок или даже отказаться от оценок, используя подход NoEstimates.