Оценка задач в Story Points

Сказка о хлебе и Story Points 

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

Сначала считал в часах и минутах — но подмастерья то филонили и долго месили тесто, то работали уж очень усердно. Понять, сколько точно им нужно времени, не получалось. К тому же один подмастерье был расторопнее и работал быстро, а другой с таким же опытом — дольше.

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

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

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

А если бы он был разработчиком, то знал, что это называется сторипоинты.

Что такое Story Points

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

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

Утренняя партия выпечки в разработке соответствует спринту — периоду времени, за который команда выполнит несколько сторипоинтов для разработки одной нужной функции. Оценку в сторипоинтах в реальном мире придумал один из авторов Scrum, Джефф Сазерленд — как альтернативу оценке задач в часах. Он заметил, что команда оценивает объём работы в идеальных днях. А настоящие дни вовсе не идеальные — людей отвлекают другие задачи, возникают внешние риски и трудности, которые влияют на работу.

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

Теперь разберём, как это работает, — не на хлебушке.

Как оценить задачу в сторипоинтах

Мы выяснили, что сторипоинт — абстрактная единица. Более того, каждая команда использует его по-своему. Поэтому со сторипоинтами можно считать задачу в чём угодно — хоть в единицах (1, 2, 3), хоть в размерах одежды (XS, M, XL), хоть в попугаях.

Но ведь и абстрактная оценка должна откуда-то взяться. Если просто сказать: «Ребята, оцените задачу как-нибудь иначе, но не в часах», то ничего не поменяется. Джун присвоит задаче сторипоинт XL, а сеньор скажет, что тут работы на XXS. 

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

Равнение по эталону

✅ Кому подойдёт. Командам, где есть понятная всем фиксированная единица работы

🔧 Как работает. К одному сторипоинту привязывают выполненную единицу работы и равняются на неё в оценке. Фактически это некая задача — скажем, набор функций. В разработке это обычно пользовательская история — та самая user story.

Если задача весит два сторипоинта, то на неё понадобится столько времени и сил, сколько на две типичных user story.

Метод Фибоначчи

✅ Кому подойдёт. Командам с довольно сильным разбросом в объёме задач

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

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

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

Метод футболок

Можно оценивать задачу в размерах футболок. Можно в котиках. А можно в футболках с размерами

✅ Кому подойдёт. Командам с предсказуемыми задачами, которые можно разделить на несколько фиксированных типов

🔧 Как работает. В этом случае сторипоинты привязываются к размерам футболок. Команда может выбрать, какие именно размеры использовать — от S до L или более широкую «размерную сетку».

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

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

✅ Кому подойдёт. Небольшим командам, особенно новым и ещё не сработавшимся друг с другом. А ещё командам с непостоянными задачами, которые сложно оценить в одиночку

🔧 Как работает. Это командная активность по оценке задач, то есть присваивании им сторипоинтов. Сами значения могут быть разными — поэтому Planning Poker можно сочетать с любым методом выше.

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

👉  Больше о покере планирования — в отдельной статье

А ещё у нас есть ролик о нём:

Сравнение с другими методами оценки задач

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

Фреймворк ICE/RICE из перечисленных ближе всего к сторипоинтам — он тоже оценивает несколько важных показателей. И, более того, подключает продуктово-маркетинговые метрики: охват и влияние на продукт. Метод довольно трудоёмкий и требует времени, но работает отлично.

Про эти методы можешь почитать отдельно в этом тексте — там есть две формулы, которые нужно использовать по фреймворку. На ICE/RICE можно тренироваться внедрять сторипоинты, а потом заменять сложные подсчёты единицами-сторипоинтами.

Value vs Effort объективнее оценки в человеко-часах, но слабее метода ICE/RICE. На нём тоже можно тренироваться внедрять сторипоинты.

👉🏻 Про эти методы мы рассказываем в отдельном тексте

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

Плюсы и минусы Story Points

Преимущества сторипоинтов

🔷 Учитывают разные аспекты задачи. Это главная фишка сторипоинтов — на оценку влияют сложность, усилия, риски и прочие факторы. А это намного объёмнее, чем просто часы. Сторипоинты в этом плане хорошо ложатся на современные тенденции отказа от оценки работы в человекочасах

🔷 Помогают оценить производительность команды. Или ещё один важный Scrum-показатель — скорость или производительность, по-английски velocity. Это вторая главная ачивка, которая открывается при переходе на сторипоинты. Если в конце спринта посчитать количество выполненных сторипоинтов, это скажет о процессах гораздо больше, чем число рабочих часов

🔷 Универсальны для всей команды. Для джуна, сеньора и менеджера задача «весит» одинаковое число сторипоинтов. Это упрощает общение по проекту. Но если правильно договориться всей командой и выстроить систему оценок

🔷 Ускоряют оценку. По статистике в сторипоинтах команды оценивают задачи на 80% быстрее, чем в часах. Вместо «Нууу, дай подумаю, мне надо часа три на эту задачу. Нет, два. Нет, четыре», разработчики будут выпаливать чёткое и однозначное «Это весит три сторипоинта». Так можно быстрее достигать результатов и не тратить ценное время 

Недостатки сторипоинтов

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

У сторипоинтов проблемы такие:

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

🔸 Использование оценок — неинтуитивная вещь, которая требует адаптации. Особенно это справедливо для новичков в команде, которая уже работает со сторипоинтами, и для команд, которые только перешли на Agile. Всегда остаётся соблазн просто приравнять сторипоинты к чему-то более реальному: к часам, например. Это недостаток, с которым можно работать — периодически проверять, как оценки сошлись с реальностью, и корректировать сами сторипоинты

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

Инструменты для работы с Story Points

Для покера планирования

Если не хочешь заморачиваться с бумажными картами, эти сайты помогут провести Planning Poker онлайн: planningpoker.com, planningpokeronline.com, planningpoker.ru, planITpoker.com

Для работы по сторипоинтам

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

В таск-менеджере WEEEK для этого идеально подойдут кастомные поля. Вот, как настроить их для работы по сторипоинтам:

Расстановка сторипоинтов, созданных в кастомном поле

Щелкай задачи на раз-два

Задачи™ — созданы для классного таск-менеджмента

Документы на стероидах

База знаний™ — создана для документов и совместного чего-то там

Воронки продаж без ворон

CRM™ — создана для продаж и ведения бизнеса

Зарегистрироваться

Расстановка сторипоинтов, созданных в кастомном поле

Ошибки при оценке в сторипоинтах — и советы от WEEEK как их избежать

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

❌ Вводить сторипоинты в новой команде

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

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

❌ Начинать со строгой системы

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

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

❌ Скрывать под Story Points человеко-часы

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

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

❌ Не считать производительность — velocity

Это не совсем ошибка, но огромная упущенная возможность. Как мы рассказали выше, velocity — производительность команды за спринт. Именно её и пытался вычислить наш пекарь, когда считал объём работы в утренней партии выпечки.

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

Совет от WEEEK. Когда адаптируетесь к системе сторипоинтов, начинайте считать velocity — количество выполненных сторипоинтов за спринт. На ретроспективах можно сравнивать производительность с прошлыми результатами и ставить цели на будущее.

Основные поинты

Щелкай задачи на раз-два

Задачи™ — созданы для классного таск-менеджмента

Документы на стероидах

База знаний™ — создана для документов и совместного чего-то там

Воронки продаж без ворон

CRM™ — создана для продаж и ведения бизнеса

Зарегистрироваться