Story Points — один из ключевых инструментов в Agile-разработке, который помогает командам оценивать задачи. Несмотря на простоту концепции, их правильное использование вызывает множество вопросов и проблем у разработчиков. Проектный менеджер CosySoft Лилит Баракян разобрала, как в действительности работают Story Points, как их правильно использовать и эффективно внедрять в реальных рабочих сценариях.
Что такое Story Points
Начнем с самого начала — возникновения этой концепции. Концепция Story Points была разработана Роном Джеффрисом в рамках гибкого метода программирования Extreme Programming как альтернатива оценке по времени. Основная идея заключалась в том, чтобы заменить временные оценки относительными понятиями усилия и сложности, которые необходимы для выполнения задачи. Позже Story Points стали частью методологии Scrum, где они приобрели широкую популярность среди Agile-команд.
Story Points — это относительная мера оценки усилий и сложности, необходимых для выполнения задачи (user story) в Agile-разработке. Команды разработчиков используют Story Points для более точной и последовательной оценки объема работ, которые могут быть выполнены за один спринт. Однако более важным является то, что процесс оценки Story Points позволяет командам уточнить объем работ и согласовать представление о завершенности задачи в целом.
Основные компоненты оценки с помощью Story Points
Итак, вместо оценки времени, которое потребуется для выполнения задачи, в SP оцениваются усилия, необходимые для решения этой задачи. При этом в эту оценку усилий следует заложить все факторы, которые могут повлиять на нее.
Объем работы
Все усилия, необходимые для выполнения задачи, включая разработку, тестирование и другие активности, прописанные в Definition of Done.
Сложность задачи
Технические сложности задачи, умственная нагрузка, количество элементов и необходимость проведения исследований.
Неопределенность
Риски и степень неизвестности, связанные с задачей в момент оценки.
Все усилия, необходимые для выполнения задачи, включая разработку, тестирование и другие активности, прописанные в Definition of Done.
Сложность задачи
Технические сложности задачи, умственная нагрузка, количество элементов и необходимость проведения исследований.
Неопределенность
Риски и степень неизвестности, связанные с задачей в момент оценки.
Разберем простой пример, который хорошо иллюстрирует суть работы Story Points
Например, у вас спрашивают, сколько весит одно яблоко. Вы можете сказать, что 250 граммов, а ваш коллега, что 100. Таким образом, вы никогда не угадаете, сколько точно весит одно яблоко и скорее всего ошибетесь в оценке.
В свою очередь, Story Points работает как относительная оценка. То есть, когда у вас спросят, сколько весит яблоко, то вы можете сравнить — яблоко тяжелее ананаса или легче. Вам не нужно говорить, что это 100 грамм или 250 — нужно лишь определить относительность. Легче, проще или сложнее. Легче или тяжелее.
Принципы работы со Story Points
Относительность оценки
Story Points измеряют относительную сложность задач. Вместо точной оценки времени, команды определяют, насколько одна задача сложнее или проще другой. Это похоже на оценку веса фруктов: вместо точного веса яблока, вы определяете, тяжелее ли оно ананаса.
Использование ряда Фибоначчи
Какой именно метод оценки выбрать, решает сама команда, подстраивая величину конкретно под свой проект. За основу можно выбрать абсолютно разные параметры. Это могут быть размеры одежды, породы собак, коробки, фрукты или попугаи — все для того, чтобы абстрагироваться от численного представления оценки.
Для числового выражения Story Points часто используется ряд Фибоначчи (1, 2, 3, 5, 8, 13, 21 и т.д.). Эта последовательность помогает учитывать рост неопределенности с увеличением сложности задачи. Чем больше число, тем больше риск и неопределенность. Важно отметить, что в этом ряду число 2 — обозначает не просто следующее за единицей число, а то, что оно в два раза больше, чем единица.
Тренируемся на попугаях и определяем скорость спринта
Метод оценки трудоемкости задач в «попугаях» заключается в сравнении задач между собой по сложности, аналогично знаменитому мультфильму: самая маленькая задача — один попугай, чуть больше — мартышка, еще больше — слоненок, и самая большая — удав. В первом спринте мы оцениваем задачи по этим категориям и определяем, сколько из них сможем выполнить. По итогам спринта подсчитываем выполненные задачи, что становится ориентиром для планирования следующих спринтов.
Таким образом через несколько итераций команда уже может измерять среднюю скорость своей работы. Это число, которое показывает сколько задач может спланировать для каждого спринта в StoryPoint'ах наша команда. Это называется velocity, то есть скорость спринта.
Velocity — это средняя скорость выполнения задач командой за один спринт. Она определяется на основе исторических данных и помогает планировать будущие спринты. В первые несколько спринтов velocity может колебаться, но со временем стабилизируется.
Со временем средняя скорость выполнения команды постепенно может повышаться или понижаться в зависимости от поставленных целей. Поначалу команда ориентируется на среднее значение на основе последних трех спринтов. И уже со временем, когда формируются исторические данные, уже можно более точно определить velocity команды и работать над ее повышением.
Покер-планирование
Метод покер-планирования используется для присвоения SP задачам. Команда обсуждает задачи и присваивает им оценки с помощью карт. Этот процесс помогает минимизировать эффект привязки (anchoring effect) и способствует более объективной оценке.
Типичные ошибки при работе с SP
1. Сведение SP только к сложности, неопределенности или объему работы
Очень важно учитывать все три компонента. Story points – это не просто либо сложность, либо неопределенность, либо объем. Это оценка усилий выполнения задач, которая сама из себя представляет совокупность всех этих трех компонентов. Каждый из них по отдельности не сможет определить объем усилий.
2. Преобразование SP в часы
Нужно полностью абстрагироваться от часов, дней, именно поэтому для начала вообще используют такие метрики, как, собаки, фрукты, коробки, майки и так далее. Не забываем о преимуществе относительности оценки.
3. Усреднение оценки
Стоит избегать усреднения значений. Если часть команды считает, что задача стоит 2 очка, а другая часть — 5, не выбирайте среднее значение 3. Вместо этого обсудите причины обеих оценок, чтобы понять, почему были выбраны именно такие значения, и уже затем принимайте решение.
4. Корректировка оценки в ходе спринта
Не меняйте оценку задачи во время спринта, даже если она оказалась некорректной. Ошибки в оценке нормальны и полезны для дальнейшего обсуждения и улучшения процесса. Корректировка оценок задним числом может исказить статистику и помешать точному планированию.
5. Оценка Spike-задач
Spike задачи — это задачи, которые команда выполняет для исследования, анализа или изучения чего-то нового, чтобы получить необходимую информацию для принятия решения. Эти задачи помогают оценить технические риски, изучить новые технологии или уточнить требования. Spike-задачи обычно имеют ограниченный временной интервал (тайм-бокс) и не требуют оценки в стори-пойнтах.
6. Изменение оценки по ключевым элементам бэклога
Если менять оценки задач во время спринта, изменится значение velocity, что приведет к потере информации, необходимой для планирования на основе исторической скорости. SP предназначены для сравнения исторических скоростей предыдущих спринтов, а не для подстройки оценок под конкретных разработчиков.
7. Переоценка незаконченных задач
Если в спринте не удалось завершить юзер-стори, оцененную в 8 SP, не нужно переоценивать ее при переносе в следующий спринт. Команда уже знает, сколько времени заняла разработка этой части задачи. А также переоценка повлияет на планирование исторической скорости.
8. Подстраивание оценки под конкретных разработчиков
SP обеспечивают относительную оценку задач, создавая универсальную шкалу, независимую от опыта оценивающего. Это позволяет сохранять оценку задачи неизменной, даже если сменится ответственный разработчик. Мы сравниваем задачи между собой, а не оцениваем, кто конкретно их будет выполнять.
9. Оценка задач не всей командой
Распределение SP играет ключевую роль в коллективном обсуждении задач. Оно представляет собой коллективное мнение всей команды, которое учитывает навыки и возможности всех участников. Поэтому важно оценивать задачи всей командой, чтобы минимизировать риски и обеспечить объективность оценки.
10. Отсутствие обсуждения неадекватных оценок на ретроспективах
Одним из преимуществ SP является возможность обсуждения ошибок на ретроспективах, чтобы предотвратить их повторение в следующих оценках. Не стоит пренебрегать этим.
11. Оценка багов
Важно различать баги, связанные с текущим спринтом, и те, которые не связаны. Связанные баги уже учтены в оценке соответствующей юзер-стори, поэтому не оцениваются отдельно в стори-пойнтах. Однако баги, не связанные с текущим спринтом, требуют отдельной оценки. Некоторые команды при оценке учитывают буфер времени на исправление багов и резервируют определенный процент времени для этой цели в течение спринта.
Преимущества использования Story Points
Скорость оценки и гибкость
SP обеспечивают возможность быстрой и точной оценки даже при большой степени неопределенности.
SP обеспечивают возможность быстрой и точной оценки даже при большой степени неопределенности.
Неважно, кто выполняет задание
Оценка в SP не зависит от навыков и опыта того, кто выполняет конкретную задачу.
Если команда согласовала определенный стори-пойнт для задачи, то абсолютно неважно, кто будет реализовать эту задачу.
Оценка в SP не зависит от навыков и опыта того, кто выполняет конкретную задачу.
Если команда согласовала определенный стори-пойнт для задачи, то абсолютно неважно, кто будет реализовать эту задачу.
Использование Velocity
SP позволяют использовать Velocity, как полезную метрику для планирования итерации и измерения производительности команды.
SP позволяют использовать Velocity, как полезную метрику для планирования итерации и измерения производительности команды.
Учет времени, затраченного на сторонние мероприятия
Оценка в SP уже включает такие активности, как встречи, код-ревью, тестирование и другие подобные процессы, которые не относятся напрямую к разработке.
Оценка в SP уже включает такие активности, как встречи, код-ревью, тестирование и другие подобные процессы, которые не относятся напрямую к разработке.
Недостатки использования Story Points
Сложность восприятия абстрактной величины
Оценка в SP может быть непонятной, особенно для тех, кто не знаком с ее концепцией.
Оценка в SP может быть непонятной, особенно для тех, кто не знаком с ее концепцией.
Трудность оценки на новом проекте
В самом начале проекта, когда еще не определено значение одного SP и нет исторической скорости команды, могут возникнуть определенные проблемы.
В самом начале проекта, когда еще не определено значение одного SP и нет исторической скорости команды, могут возникнуть определенные проблемы.
Не подходит для мелких проектов
SP не применяются для некоторых видов проектов. Например, абсолютно нет смысла использовать SP для краткосрочных проектов или проектов, где участвует всего один разработчик.
SP не применяются для некоторых видов проектов. Например, абсолютно нет смысла использовать SP для краткосрочных проектов или проектов, где участвует всего один разработчик.
Сложности при расчете бюджета
Оценка проекта в SP затрудняет расчет бюджета, так как стори-пойнты нужно преобразовать в человекочасы. Для этого можно использовать бэклог, уже оцененный в SP. Определив количество спринтов, необходимых для выполнения бэклога, и зная velocity команды, можно вычислить временные затраты и бюджет. Важно предварительно оценить весь бэклог, чтобы эти расчеты были точными.
Оценка проекта в SP затрудняет расчет бюджета, так как стори-пойнты нужно преобразовать в человекочасы. Для этого можно использовать бэклог, уже оцененный в SP. Определив количество спринтов, необходимых для выполнения бэклога, и зная velocity команды, можно вычислить временные затраты и бюджет. Важно предварительно оценить весь бэклог, чтобы эти расчеты были точными.
Как справиться с влиянием разных грейдов и опыта разработчиков на оценку задач
Корректная оценка задач является ключевым этапом, который напрямую влияет на планирование и успех проекта. Однако одна из главных проблем, с которой сталкиваются команды, — это различие в опыте и квалификации разработчиков. Новички могут оценивать задачи иначе, чем опытные специалисты, что приводит к расхождению в оценках и затрудняет планирование. Рассмотрим, как эффективно справляться с влиянием различных уровней опыта и квалификации разработчиков на оценку задач и какие методы могут помочь в этом процессе.
Сравнивать задачи, а не числа
Важнее сравнивать задачи между собой, чем привязываться к числам или времени. Основная цель оценки — выявить относительную сложность задач. Можно начать с самой мелкой задачи, оцениваемой в единицу, и от нее оценивать остальные: сложные — выше, простые — ниже. Это позволяет команде абстрагироваться от чисел и сосредоточиться на реальной сложности задач.
Важнее сравнивать задачи между собой, чем привязываться к числам или времени. Основная цель оценки — выявить относительную сложность задач. Можно начать с самой мелкой задачи, оцениваемой в единицу, и от нее оценивать остальные: сложные — выше, простые — ниже. Это позволяет команде абстрагироваться от чисел и сосредоточиться на реальной сложности задач.
Детально обсуждать задачи на груммингах
Чтобы преодолеть влияние разного опыта и грейдов разработчиков, необходимо регулярно проводить грумминги для детального обсуждения каждой user story. Это помогает всей команде лучше понять задачи, выявить риски и факторы, влияющие на оценку, и обеспечивает единое понимание задач среди всех членов команды. Обсуждение позволяет новеньким разработчикам быстрее понять сложность задач и научиться оценивать их наравне с опытными коллегами.
Чтобы преодолеть влияние разного опыта и грейдов разработчиков, необходимо регулярно проводить грумминги для детального обсуждения каждой user story. Это помогает всей команде лучше понять задачи, выявить риски и факторы, влияющие на оценку, и обеспечивает единое понимание задач среди всех членов команды. Обсуждение позволяет новеньким разработчикам быстрее понять сложность задач и научиться оценивать их наравне с опытными коллегами.
Регулярно проводить ретро
Регулярные ретроспективы необходимы для анализа прошлых оценок и выявления ошибок. Обсуждение на ретро помогает команде понять, почему оценки оказались неверными, и учиться на этих ошибках. Такой подход способствует улучшению процессов оценки и повышению качества планирования в будущем, укрепляя командное взаимодействие и общую производительность.
Регулярные ретроспективы необходимы для анализа прошлых оценок и выявления ошибок. Обсуждение на ретро помогает команде понять, почему оценки оказались неверными, и учиться на этих ошибках. Такой подход способствует улучшению процессов оценки и повышению качества планирования в будущем, укрепляя командное взаимодействие и общую производительность.
Создать эталонные оценки
Создание эталонных задач для ориентировки позволяет разработчикам соотносить новые задачи с уже выполненными и оцененными. Например, простые задачи могут оцениваться как «единица», средние — как «двойка», а сложные — как «пятерка». Это помогает команде быстро ориентироваться и оценивать новые задачи, основываясь на предыдущем опыте и типичных примерах, которые легко можно понять и применить к текущим задачам.
Создание эталонных задач для ориентировки позволяет разработчикам соотносить новые задачи с уже выполненными и оцененными. Например, простые задачи могут оцениваться как «единица», средние — как «двойка», а сложные — как «пятерка». Это помогает команде быстро ориентироваться и оценивать новые задачи, основываясь на предыдущем опыте и типичных примерах, которые легко можно понять и применить к текущим задачам.
Поддерживать атмосферу открытого общения
Эффективная оценка задач требует открытого обмена мнениями в команде. Важно создать атмосферу, где каждый участник может свободно высказываться, обсуждать сложности задач и учиться на своих ошибках. Оценка задач — это процесс, который не требует постоянного совершенствования, а направлен на улучшение командной работы и планирования.
Эффективная оценка задач требует открытого обмена мнениями в команде. Важно создать атмосферу, где каждый участник может свободно высказываться, обсуждать сложности задач и учиться на своих ошибках. Оценка задач — это процесс, который не требует постоянного совершенствования, а направлен на улучшение командной работы и планирования.
А что насчет классической оценки в часах?
Оценка задач в часах — один из самых традиционных методов планирования времени и ресурсов в проектном управлении. Этот подход остается популярным благодаря своей простоте и интуитивной понятности. Однако, как и любой другой метод, оценка в часах имеет свои плюсы и минусы.
К плюсам можно отнести простоту восприятия такой оценки, отсутствие зависимости от величины проекта, понятное прогнозирование о сроках и ключевых этапах проекта, а также возможность и прозрачность для прогноза и отслеживания бюджета проекта. Но недостатков тоже достаточно.
Сложность оценки при наличии рисков
Сложно дать точную оценку задачи в часах, когда существует много неопределенностей относительно ее выполнения.
Сложно дать точную оценку задачи в часах, когда существует много неопределенностей относительно ее выполнения.
Зависимость оценки от навыков разработчика
Оценка в часах сильно зависит от того, кто именно выполняет задачу.
Оценка в часах сильно зависит от того, кто именно выполняет задачу.
Задачу оценивает тот, кто ее выполняет
Если один разработчик оценивает задачи, а другой их выполняет, оценка может быть полностью нерелевантной.
Если один разработчик оценивает задачи, а другой их выполняет, оценка может быть полностью нерелевантной.
Не учитывается время, потраченное на сторонние мероприятия
Оценка в часах обычно не учитывает время, которое разработчики проводят на мероприятиях, не относящиеся напрямую к разработке заданий.
Оценка в часах обычно не учитывает время, которое разработчики проводят на мероприятиях, не относящиеся напрямую к разработке заданий.
Несколько важных заметок и вопросов
Как справиться с влиянием разных грейдов и опыта разработчиков на оценку задач?
Корректная оценка задач является ключевым этапом, который напрямую влияет на планирование и успех проекта. Однако одна из главных проблем, с которой сталкиваются команды, — это различие в опыте и квалификации разработчиков. Новички могут оценивать задачи иначе, чем опытные специалисты, что приводит к расхождению в оценках и затрудняет планирование. Рассмотрим, как эффективно справляться с влиянием различных уровней опыта и квалификации разработчиков на оценку задач и какие методы могут помочь в этом процессе.
Сравнивать задачи, а не числа
Важнее сравнивать задачи между собой, чем привязываться к числам или времени. Основная цель оценки — выявить относительную сложность задач. Можно начать с самой мелкой задачи, оцениваемой в единицу, и от нее оценивать остальные: сложные — выше, простые — ниже. Это позволяет команде абстрагироваться от чисел и сосредоточиться на реальной сложности задач.
Детально обсуждать задачи на груммингах
Чтобы преодолеть влияние разного опыта и грейдов разработчиков, необходимо регулярно проводить грумминги для детального обсуждения каждой user story. Это помогает всей команде лучше понять задачи, выявить риски и факторы, влияющие на оценку, и обеспечивает единое понимание задач среди всех членов команды. Обсуждение позволяет новеньким разработчикам быстрее понять сложность задач и научиться оценивать их наравне с опытными коллегами.
Регулярно проводить ретро
Регулярные ретроспективы необходимы для анализа прошлых оценок и выявления ошибок. Обсуждение на ретро помогает команде понять, почему оценки оказались неверными, и учиться на этих ошибках. Такой подход способствует улучшению процессов оценки и повышению качества планирования в будущем, укрепляя командное взаимодействие и общую производительность.
Создать эталонные оценки
Создание эталонных задач для ориентировки позволяет разработчикам соотносить новые задачи с уже выполненными и оцененными. Например, простые задачи могут оцениваться как «единица», средние — как «двойка», а сложные — как «пятерка». Это помогает команде быстро ориентироваться и оценивать новые задачи, основываясь на предыдущем опыте и типичных примерах, которые легко можно понять и применить к текущим задачам.
Поддерживать атмосферу открытого общения
Эффективная оценка задач требует открытого обмена мнениями в команде. Важно создать атмосферу, где каждый участник может свободно высказываться, обсуждать сложности задач и учиться на своих ошибках. Оценка задач — это процесс, который не требует постоянного совершенствования, а направлен на улучшение командной работы и планирования.
Нужна ли оценка в стори-пойнтах, если заказчику не важны спринты?
Выбор метода оценки задач зависит от внутренних потребностей команды и специфики проекта. Использование SP для оценки задач необязательно, если заказчику не важны спринты и итеративное планирование. Основная цель стори-пойнтов — облегчить планирование и управление проектом внутри команды, предоставляя универсальную шкалу для оценки задач. Если команда не нуждается в упрощении планирования и может эффективно управлять проектом иными способами, то использование стори-пойнтов не является необходимым.
Нужны ли Story Points на проекте, если можно самостоятельно определить время релиза в днях?
Использование Story Points не является обязательным, если команда способна самостоятельно определить время релиза в днях. Однако, Story Points предоставляют ценное понимание сложности и объема работы, что способствует более точному планированию и управлению проектами. Они помогают команде оценить, сколько задач можно выполнить за определенный период, и позволяют использовать метрику velocity для анализа производительности. Velocity позволяет сравнивать данные различных спринтов, выявлять проблемные моменты, улучшать процессы и повышать эффективность работы. Исторические данные по velocity дадут возможность команде анализировать свои сильные и слабые стороны, находить области для улучшения и принимать меры по совершенствованию процессов разработки.
Как оценивать задачи с новой командой, которая никогда не работала вместе?
Начинать работу с оценки в Story Points может показаться сложным, особенно если команда впервые работает вместе. Однако, можно применить метод сравнения задач друг с другом, начиная с определения наименьшей задачи, которую можно назвать единицей. Затем, сравнивая каждую следующую задачу с уже оцененными, можно определить их относительную сложность. При этом, важно учитывать риски и невыясненные обстоятельства каждой задачи, чтобы более точно распределить их по шкале сложности.
Заключение
Story Points — это метод оценки, основанный на сравнении задач между собой, где каждая задача оценивается относительно других уже оцененных задач. Этот метод позволяет быстрее и проще оценивать задачи по сравнению с оценкой во времени, которая требует точных значений и может быть подвержена большему риску ошибок. Story Points учитывают риски, неопределенности и предыдущий опыт команды, предоставляя коллективную оценку, основанную на общих навыках и возможностях, а не на индивидуальных способностях. Для правильного использования Story Points необходимо понимание их природы и принципов работы, а также опыт и практика. Избегайте распространенных ошибок и постоянно совершенствуйте процессы оценки, чтобы достичь максимальной эффективности и согласованности в команде.
