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

Так что решилась написать максимально прикладную (приложу все усилия) статью про то что это такое, какие есть недостатки, ошибки в использовании, и как же это всё внедрить (если они реально вам подходят).

Всем привет) Я - Саша Зебелева, налаживаю процессы в IT командах.
Регулярно пишу в свой канал про жизнь и работу. Заходите на огонек 🔥

Ключевые выводы статьи:

Главный критерий выбора системы оценки - повышение предсказуемости работы команды. Если текущий подход обеспечивает достаточную предсказуемость, возможно, менять его не стоит.
Story points - это командная, относительная оценка объема работ, учитывающая сложность, риски и "транзакционные издержки". Они особенно эффективны для кроссфункциональных команд со стабильным составом.
Использование story points как метрики эффективности или попытка унифицировать их между разными командами приводит к искажению оценок и потере их основной ценности.
При внедрении важно учитывать контекст команды: состав, опыт, тип задач и процесс поставки. Не существует универсального подхода - выбирайте то, что работает именно в вашем случае.

Осторожно в статье ОЧЕНЬ много букв. Поэтому рекомендую обратиться к содержанию, а там уже двигаться по ссылкам. А ещё можно сначала глянуть мой доклад на Saint TeamLead Conf, а потом вернуться сюда и посмотреть детальнее.

В этой статье мы пойдем по такому плану:

Общее время чтения: примерно 1 час 33 минуты

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

Поехали!

1. Краткие теоретические основы про оценку объема работ

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

Предисловие

По моему опыту, выбор той или иной системы оценки объема работ это всегда выбор из существующего контекста. Но есть одна вещь, которую я предлагаю брать за мерило того, насколько в вашем контексте подходит вам тот или иной способ.

Это предсказуемость работы команды.

Ведь в конечном счете вся суть планирования заключается в том, что даем комитмент, на который другие опираются. Через это мы стараемся быть предсказуемыми для других. В таком случае "Точность оценки - показатель эффективности системы"(Дэвид Андерсон. Канбан. Альтернативный путь в Agile)

Если при новом способе оценки предсказуемость повышается - оставляем, если повышается хаос и неопределенность - "выкидываем и поскорей". Тоже самое и в стартовой точке, если вашей предсказуемости работы команды вам хватает, вы попадаете в сроки, заказчики довольны - то может и не надо вам менять способ оценки объема работ?

Поэтому здесь и далее в этой статье буду использовать вместо "насколько это эффективно?" формулировку "делает ли эту работу команды более предсказуемой?".

Что это такое оценка объема работ, что в себя включает?

Оценка - сумма прогнозируемых усилий, которые потребуются для завершения работы над фичей\задачей.

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

При прогнозировании усилий нам важно учесть:

Объем работы.

Есть разница, мы хотим собрать\сделать 1 стул или всю мебель (кровать, шкаф, стулья и т.д.) в квартире.

Сложность.

Есть разница, мы хотим написать сочинение "Как я провел лето?" или пьесу для постановки в театре.

Риски.

Новая задача\фича это всегда неопределенность. Определено только то, что уже есть, уже создано. Любая неопределенность несет в себе риск. Мы люди, мы можем что-то не учесть, не предвидеть и т.д. Часто мы ещё и зависим от мира вокруг: возможно, прямо сейчас вашу квартиру заливает сосед сверху - вы не можете это предсказать, это риск. Тоже самое в командах. Мы можем зависеть от того, когда они приступят или закончат свою часть работы. Сверху ещё требования различных регуляторов, изменения рынка, глобальные события. Мир изменчив, это нормально. Наша задача обработать эти риски, насколько это возможно.

Где начинаются наши усилия?

Чтобы померить длину отрезка, вам нужна не только линейка, но четко видеть начало и конец отрезка. Тут тоже самое. От какой условной точки мы начинаем мерить объем работы? Где начинается оцениваемый отрезок? В каком стартовом состоянии задача\фича? Какое состояние на сегодня - As Is? Что у нас в принципе есть по задаче? Насколько она готова к тому, чтобы взять её в работу?

Вы можете определять это по каждому тикету отдельно.

Или ввести DoR (Definition of Ready) для всех задач, попадающих в вашу команду. То есть по любой задаче не может быть начата работа, если она не соответствует DoR.

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

Итого: нам\команде\исполнителю прежде чем оценить объем предстоящей работы нужно понять, а в каком месте эта работа будет начинаться.

Где наших усилий уже не нужно?

То же самое с финишем. До какой точки отрезок, который нужно померить? Где заканчивается работа нашей команды?

Тут вам могут помочь критерии приемки - индивидуальные критерии для каждой задачи, как мы поймем, что то, что мы сделали правильно\удовлетворяет запрос клиента\заказчика?

Также может помочь DoD (Definition of Done) - универсальный список критериев для завершения любой работы.

Пример
Команда создает и развивает продукт по хранению и использованию данных о пользователях по всем продуктам экосистемы. Архитектору данных поста��лена задача: продумать и придумать, как оптимальней структурировать средний слой данных из сырых источников в новом хранилище.
Дейли команды:
- Что ты делал вчера? Что будешь делать сегодня?
- Я шатаю структуру данных.
Дейли через 2 недели:
- Я шатаю структуру данных.
Дейли через 2 месяца:
- Я шатаю структуру данных.

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

2. Способы оценки объема работ

В этом разделе мы рассмотрим различные подходы к оценке объема работ в проектах. Разберем три основных концептуальных способа - абсолютную оценку, относительную оценку и подход no estimate, а также два дополнительных паттерна - "авторитет" и "сроки".

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

Концептуально есть 3 способа оценки объема работ:

Абсолютная оценка

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

No estimate

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

Авторитет

В команде есть человек (чаще всего лид), который с высоты своего опыта и знаний оценивает объем работ по каждой задаче. И в целом не так важно, ставит он оценки в баллах, часах или еще как-то.

Плюсы:

Быстро. Экономим время на оценке. Нам не нужно собирать команду и обсуждать задачу. Для оценки нужен только лид и немного его времени.
Оценка от "лида" - это челлендж. У лида обычно действительно большой опыт, и у него есть продакт/бизнес, который на него давит. Он не будет оценивать задачи сложнее и объемнее, чем они есть на самом деле.
В случае неопытной зеленой команды позволяет в целом вообще как-то планироваться, а не просто плыть по течению.

Минусы:

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

Сроки

Вместе с любой задачей команде поступает и срок её выполнения. Срок этот не подлежит обсуждению. Команда всегда занимается тем, что пытается влезть в этот срок, "порвав на себе все рубашки".

Плюсы:

Быстро. В принципе не тратим время на оценку как таковую, просто получаем срок.
Если и происходит оценка, то она приобретает практически бинарный характер "реально/нереально". В случае "нереально" срок не факт, что двигается, скорее это эскалируется наверх и ищутся доп. ресурсы для того, чтобы стало реально.
Супер удобно заказчикам. Их сроки, они им понятны, удобны.

Минусы:

Отсутствие гибкости в оценках. Если что-то пойдет не так (а что-то обязательно так и произойдет), то это снизит предсказуемость разработки до 0.
Сроки всегда нереалистичны, поскольку их ставит не тот, кто будет реализовывать эту задачу.
Команда выгорает, поскольку попасть в срок заказчиков - это часто недостижимая цель. Успеха нет, растет неудовлетворенность собой/командой/процессом/компанией.

Теперь вернемся к концептуальным способам.

Абсолютная оценка

Те самые часы, дни, человеко-часы, идеальные дни помноженные на коэффицент и т.д. Всё то, что так или иначе привязано ко времени.

Плюсы:

Универсальная единица измерения. Её понимают одинаково все: исполнители, руководители, заказчики, клиенты, родственники.
Час это всегда 60 минут. На работе, дома, в подвале, в парке, в Китае и в Новой Зеландии и т.д.
Заказчиков чаще всего интересует “когда” будет готово на этот вопрос как раз отвечают единицы времени положенные на загрузку команды. Поэтому легко обсуждать и “торговаться” часами, днями и тд. Давая оценку часами, мы отвечаем сразу на 2 вопроса: сколько нужно усилий? сколько нужно времени для реализации этих усилий?.
Поддерживает индивидуальный стиль работы. В командах, где каждый получает свою задачу и каждый сам может дотащить её до прода, это на руку. Люди не тратят своё время на командное обсуждение задач.
Очень удобны для планирования дня. Так или иначе команде важно скоординироваться и договориться конкретному Васе и Пете, когда, что и кто из них сделает. В масштабе дня часы наиболее удобны, как раз за счет мелкой гранулярности и универсальности.

Минусы:

Несмотря на то, что часы универсальная единица измерения, люди физиологически хуже справляются с точной оценкой в единицах измерения. Попробуйте прямо сейчас сказать сколько до минуты вы тратите времени на душ. Если вы не делали специальных усилий ранее, то дать точный ответ до минуты у вас не получится.
Час работы одного человека ≠ час работы другого. Есть дж��ны, мидлы, сеньоры. Даже у двух крутых сеньоров будет разный набор компетенций и опыт. При планировании нужно будет всегда учитывать кто конкретно будет делать эту задачу, пересчитывать нагрузку на каждого человека, балансировать и т.д.
Оценивая в часах мы пытаемся ответить сразу на 2 вопроса:
- какой объем работы в этой задаче?
- сколько на этот объем работы понадобится времени?
А тут как в статистике если сразу тестируешь 2 гипотезы, то вероятность ошибки кратно выше.

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

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

Те самые storypoints, майки (XS, S и т.д.), степени двойки, баллы, попугаи и т.д. В общем, всё то, что не имеет привязки ко времени.

Относительная оценка также имеет свои плюсы и минусы.

Плюсы:

Оценка основана на эмпирическом опыте конкретно этой команды.
Учтены “транзакционные издержки” (читай - командная работа) ведь оценка происходит через опыт уже завершенных задач.
Точность оценки повышается, поскольку мы разделяем 2 вопроса и отвечаем только на “сколько усилий потребует эта задача?”. 1 гипотеза - вероятность ошибки ниже.
Субъективность оценки переходит из индивидуальной в командную. Вот эта команда оценила эту задачу в 5 сторипоинтов, а другая команда в 13 сторипоинтов. И обе правы.
Заказчик не триггерится, если мы в свете изменений немного скорректировали оценку. Потому что для него важен срок, а не то сколько попугаев мы насчитали в этой задаче.
Сторипоинты хороший инструмент для среднесрочного планирования. От недели до пары месяцев. Планировать день и планировать квартал уже нужны другие единицы измерения.

Минусы:

Если у команды ещё нет опыта работы в новом контексте, то опираться не на что и это будут выстрелы наугад.
Заказчикам непонятны единицы измерения. Их интересует срок, когда это будет сделано и этот срок нужно будет им дать дополнительно.
Сторипоинты нельзя сравнивать между командами. 1 сторипоинт команды “X” ≠ 1 сторипоинту команды “Y”.
Для планирования кварталов и больше, сторипоинты уже не подойдут. Это слишком большой горизонт планирования. И для планирования дня тоже уже не подойдут, слишком неточны и не дают конкретной картинки.

Плюсы и минусы абсолютной и относительной оценки

No estimate

Также есть практика из Kanban. В своей книге Дэвид Андерсон как раз, рассказывает об этой практике с позиции, что оценки всегда не точны. Команда тратит кучу времени на этот процесс, но все равно не попадает в свои оценки. Тогда начинается гонка за точностью, команда тратит еще больше времени, а точности не появляется. В итоге вся работа команды фокусируется не на поставке ценности, а на точности предоставленных оценок, а это уже идет в разрез со всеми ценностями и принципами Kanban и Agile и, что важнее, сокращает время на енпосредственную работу (создание и поставку ценности). В итоге ради экономии времени и сил, а также чтобы восстановить фокус на поставке появилась идея вообще отказаться от оценок объема работ. No estimate.

No estimate заключается в том, что мы за счет стабилизации системы и на основе статистики работы нашей команды заключаем “соглашение об уровне услуг” - SLA. Выглядит оно примерно так:

“Мы как команда (или я как тимлид) гарантирую что 80% поступивших к нам задач с вероятностью 85% будут завершены в течении 30 дней “.

Вместо этих цифр вы подставляет те, что вывели статистически через диаграмму распределение времени работ и вуаля. Больше оценивать объем работ не нужно. Ваша задача сфокусироваться только на выполнении этого SLA.

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

Сравнение абсолютного и относительного подходов, в каких случаях что больше подходит.

На какие вопросы нужно найти ответы чтобы выбрать способ оценки объема работ?

	Абсолютная оценка объема работ	Относительная оценка объема работ
Усилий скольких участников вашей команды нужно в большинстве случаев\задач попадающих в вашу команду?	Если индивидуальная работа участников команды составляет больше 85% всей работы команды	В команде 85% задач для решения которых понадобятся усилия двух и более участников команды
Участники вашей команды выполняют одну и ту же функцию или разные?	В случае монофункциональных команд (например, команда аналитиков, которая решает задачи от всего департамента; техподдержка)	Кроссфункциональная команда (например, в команде бэкендер, фронтендер, тестировщик и т.д.)
Какой есть опыт у команды?	Команда только собрана и ещё ничего не знает о своей производительности. Или в целом ситуация в команде и компании так часто меняется, что у команды нет возможности нажить тот самый командный опыт решения задач. Например, высокая текучка в команде.	Команда стабильна, есть уже нажитый опыт. Есть данных о завершенных этой командой задачах за последние 3-6 месяцев.
Как проходит процесс поставки ценности в целом в системе нескольких команд\департамента? Отдаете ли вы задачу другой команде и ожидаете её возвращения для продолжения работ или нет?	Если вы отдаете задачу и потом обогащенная, она возвращается в вашу команду для дальнейших работ. (например, вы подготовили фичу, отдали в команду тестирования, а потом они возвращают её вам чтобы вы выкатили ее прод). То здесь сторипоинты будут показывать слишком большую погрешность и не будут отражать прозрачную картину. Поэтому возможно лучше подойдут часы.	Если просто отдаете дальше куда-то задачку (например, у вас отдельная команда мобильных тестировщиков на весь департамент и через них проходят задачи от многих команд) то это ок и тут тоже зайдут сторипоинты. Просто точка завершения работ для вас будет немного размыта и еще не Done. (Евангелисты могут меня тут покритиковать, но опираясь на свой опыт, говорю что сторипоинты - в половине таких случаев, дадут прирост предсказуемости)

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

3. Относительная оценка - Storypoints

И вот теперь, когда вы сделали осознанный выбор в сторону Storypoints, давайте, наконец, посмотрим на них подробнее.

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

Откуда взялись storypoints?

И вообще, кто их придумал?

И уже тут расходятся мнения. Одни будут говорить, что это Джефф Сазерленд (Scrum), другие будут называть Рона Джефриса («Обдумывая сторипоинты»), третьи укажут на Фредерика Брукса («Мифический человеко-месяц»).

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

Джефф Сазерленд, скорее всего, искал способ оптимального планирования и саморегулировки команды, исходя из уровня качества (DoD) и возможностей самой команды.

У Рона Джефриса сторипоинты — это идеальные человеко-дни, разложенные и адаптированные под реальные дни. А чтобы заказчики не триггерились, в названии ушли от «часов» и появились «поинты».

Фредерик Брукс (насколько я смогла выяснить) ничего вообще о сторипоинтах не говорил, а скорее говорил о том, что время выполнения проекта не обратно пропорционально числу программистов. То есть от того, что мы добавим в команду еще исполнителей, время выполнения проекта не сократится, а, наоборот, увеличится («Закон Брукса»). Хотя, казалось бы, количество часов распределится на больше исполнителей, а значит, каждый справится со своей работой быстрей. Но нет.

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

Как устроена относительная оценка

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

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

Какие есть вариации на практике

Ряд Фибоначчи (1,2,3,5,8,13,21) — один из самых популярных. Могут называться баллами, сторипоинтами и даже попугаями и т.д. Увеличивающаяся дельта между последующими цифрами дополнительно отражает рост рисков при укрупнении объема оценки задачи.

Футболки (XS, S, M, L, XL) — также очень популярны. По сути, тот же ряд Фибоначчи, только без упоминания цифр. Я рекомендую, если вы переходите от оценки часов к сторипоинтам, его, поскольку нет цифр, на которые хотелось бы опереться и просто найти оптимальный коэффициент умножения часов для перевода в сторипоинты.

Степени двойки (2,4,8,16,32) — редко встречается, но почему нет.

Животные, кодовые названия. Встречаются довольно редко, но тоже вполне валидны. Например:

Мышка, кошка, собака, обезьяна, корова, слон, кит.
Изян, норм, ну такое, жесть, жесткач, треш.

Как происходит относительная оценка объема работ?

В одном пространстве мы собрали команду, которой предстоит сделать некоторый пул задач. Смотрим на первую из них, смотрим требования и/или use case, ограничения, «зачем?» и вообще всё, что известно по этой задаче. Дальше команда, обсуждая задачу, называет некоторую оценку. Важно, чтобы все участники команды были согласны с оценкой хотя бы частично (в идеале — полностью согласны).

Именно эту оценку мы и записываем в задачу.

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

Оценка по референсной таблице
Оценка по эталонной задаче
Покер-планирования

Оценка по референсной таблице

Не скрою, мой любимый подход.

Чтобы обсуждение оценки в команде проходило не на примерах из воздуха и допущениях допущений, а на конкретном опыте, мы собираем референсную таблицу по уже завершенным задачам этой команды. Что мы оцениваем по конкретным задачам как то или иное количество сторипоинтов.

Пример таблицы

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

Оценка по эталонной задаче

То же самое, что и референсная таблица, но только по одной задаче. Обычно берется небольшая задача, чтобы не было необходимости ставить оценки меньше 1 (0,5, 0,7 и т.д.)

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

Покер-планирования

Не буду сильно углубляться, почитать подробнее можно тут.

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

Пример использования - как встраивается в процессы работы команды

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

Планирование

При использовании относительных оценок объема работ со временем вы сможете накопить уже какую-никакую статистику по динамике вашей команды. Сколько сторипоинтов они сжигают за неделю/спринт.

По-честному это делается так. Вам необходимо взять и посмотреть прошедшие спринты на предмет завершенных полностью задач (целиком задач, а не просто завершенные sub-tasks). И посчитать, сколько за спринт вы успеваете обычно. Очень часто берут среднее за последние 3-4 спринта или медиану, что в вашем случае будет более показательно - решать вам. Это ваш реальный capacity.

НО ВАЖНО ПОНИМАТЬ, что это ориентир при планировании. То есть ваш получившийся capacity - это скорее отправная точка. Если вы видите, что продакт вам напихивает в X раз больше, то вы можете отбить лишнее, аргументировав это цифрой Capacity. Если команда на кураже и амбициозная, вы можете взять побольше, чем capacity, если команда устала или пришло много новичков - взять меньше, чем ваша цифра capacity. Понимаете, что будет много зависимостей от других команд и рисков, - берите меньше. И так далее.

Груминг

Уточнение элементов бэклога продукта. Ну или проработка и подготовка задач для последующих спринтов. В Scrum на груминг уходит не больше 10% времени текущего спринта, и прорабатываются самые приоритетные элементы бэклога. Также в рамках груминга как раз и выставляется оценка объема работ. Часто этот вопрос вызывает дополнительное обсуждение деталей задачи, а значит, способствует выравниванию в понимании по задаче как команды внутри, так и продакта и команды, а в некоторых случаях и команды и заказчика.

DoR

До какого состояния нам нужно подготавливать задачки к будущим спринтам? Ответом на это является Definition of ready (DoR). В рамках одного из пунктов этого чеклиста может быть «есть оценка объема работ». Тем самым мы дополнительно усиливаем правило проработки задач до взятия в работу. Повышаем возможности для прозрачности и предсказуемости работы команды.

DoD

Чтобы сократить разнообразие в понимании того, какой объем мы оцениваем, можно использовать Definition of Done (DoD). Он позволяет не тратить время на объяснение по каждой задаче, что будет финалом, а значит, упростит оценку объема работ.

4. Ошибки и внедрение Storypoints

1 сторипоинт = N часов

Наверное, один из самых распространенных паттернов. И у такого варианта даже есть свои основания. Ведь Рон Джефрис, придумывая сторипоинты, взял идеальные человеко-дни и просто приложил их на реальность - вот и получились сторипоинты.

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

Но давайте оставим громкие методологические споры евангелистам. Нас интересует максимально прикладная сторона вопроса. Поэтому давайте разложим, какие эффекты дает нам такое использование сторипоинтов.

Если 1 сторипоинт равен N часам, то:

мы прячем для заказчика часы, и теперь нам проще корректировать (при необходимости) оценку объема работ
каждый участник команды может отдельно, индивидуально оценивать свою работу в часах, а потом удобно переводить это в сторипоинты
такие сторипоинты у сениора и джуна будут сильно разными, это нужно будет всегда учитывать при планировании поставки
мы все также отвечаем сразу на два вопроса (пусть и только самим себе), а в случае, как мы помним, 2 гипотез вероятность ошибки выше
если работа предполагает командный характер, мы все также можем упустить транзакционные издержки

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

Норма выработки

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

Или же лучше давайте наш capacity поделим на количество человек в команде и будем на планировании проверять, что все взяли не больше и не меньше этой нормы!

Но, к сожалению, нет. Из способа оценить предстоящую работу и отказаться от того, что не влезает, вы перешли к инструменту замера эффективности. А любой инструмент мониторинга эффективности всегда читерится и взламывается, ведь, по сути, подкрутить цифру всегда проще, чем работать над собственной производительностью (см. Закон Гудхарта).

В ��тоге у нас и сторипоинты больше не отражают реальный прогноз усилий, а отражают приближение к норме, чтобы нас не поругали. Да и инструмента контроля из этого толком не выходит, потому что команда при большем давлении так или иначе будет читерить и хитрить, а значит, валидной картины и возможности похвалить/наказать прозрачно нет.

Индивидуальные сторипоинты

Фронтенд говорит, что у него на задачку уйдет 3 сторипоинта, бэкенд говорит еще 5 сторипоинтов, тестировщик говорит еще 8 сторипоинтов. Еще одна распространенная засада.

Сторипоинты - это всегда комплексная, командная оценка. Мы не считаем отдельно кусочки по функциям, мы оцениваем, насколько весь объем работы по этой задаче больше или меньше других задач. В этом вся суть.

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

Личный/командный коэффициент

Этот кейс встречается и в паре с индивидуальными сторипоинтами, так и самостоятельно. Суть в том, что если задачку берет джун, то оценку его задачи умножают на Х (например, на 2), если миддл - оставляют как есть, если сеньор - то делят на Y (например, на 2).

Сторипоинты оценивают задачу, а не свой личный вклад. Мы сравниваем ��бъем разных задач друг с другом, а не примеряем, кто будет делать то или другое.

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

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

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

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

Чтобы это все было прозрачно и понятно, давайте сделаем для всех некоторый эталон сторипоинта. Ну чтобы все команды одинаково понимали, сколько это 1 сторипоинт, сколько 2.

А там еще и соревновательный аспект подтянется! Кто хочет быть командой-аутсайдером в департаменте и привлекать к себе внимание большого начальника?

Затея с рейтингом очень рискованная, см. ошибки выше и читерство с метриками эффективности.

Каждая команда занимается чем-то своим, у каждой своя не пересекающаяся с другими зона ответственности. Каждая команда имеет свой уникальный состав, свой уникальный набор компетенций, условий работы, процессы, свои сторипоинты. На самом деле, в таком случае абсолютно нормально, что одна команда оценит задачу в 3 сторипоинта, а другая в 47 сторипоинтов. У них разная история, разная динамика и т.д.

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

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

Инструкция как внедрить сторипоинты

Статья и так получилась очень большой, так что оставлю здесь готовую инструкцию для скачивания.

Подробную, развернутую инструкцию можно найти у меня в канале.

А для желающих проверить себя есть курс в котором, как раз множество ситуаций кейсов для отработки.

Эпилог

Оценка объема работ в вашей команде/департаменте должна вам помогать, а не мешать работать.

Если подход можно упростить и облегчить, а предсказуемость и прозрачность не пострадают, то почему и нет. Давайте упрощать!

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

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

Зачем нужны и как использовать storypoints?