Истории в баллах: руководство по оценке пользовательских историй в Agile

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

Именно здесь на помощь приходят методы оценки. С помощью таких методов, как Story Points, вы сможете точно определять объём работ, что даст вам и вашей команде более чёткое представление о том, сколько усилий потребуется для выполнения заданий и где могут возникнуть проблемы. Давайте рассмотрим преимущества Story Points и способы их использования. 

Что такое баллы для пользовательских историй?

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

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

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

• Повторение — это опыт команды в выполнении похожих заданий. 

• Сложность — это уровень трудности задания (и насколько ясны его цели). 

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

Стори поинты в сравнении с оценкой по времени

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

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

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

Шесть шагов по внедрению и оценке стори поинтов

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

1. Представьте своей команде Story Points

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

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

2. Определите шкалу оценки 

Затем определите последовательность баллов. Это будет метод, который ваша команда будет использовать для назначения баллов на совещании по оценке (подробнее об этом позже). Последовательности полезны тем, что заставляют команду сосредоточиться на относительном размере между числами, что упрощает оценку сложных заданий. Итак, какую последовательность следует использовать? В Agile для оценки часто используют последовательность Фибоначчи — ряд чисел, в котором каждое число является суммой двух предыдущих. Но она может быть сложной. Если ваша команда не справляется с числовыми значениями, попробуйте размеры футболок. Как следует из названия, эта последовательность разбивает задания на более управляемые размеры на основе размеров футболок: XS, S, M, L, XL и XXL. 

Совет: при оценке в Agile команды обычно меняют последовательность Фибоначчи на 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 и 100 для простоты использования. 

3. Создание матрицы баллов для историй

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

Как видите, значения Story Point увеличиваются по мере роста трудозатрат, сложности и риска, связанных с заданием. 

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

4. Проведите совещание по планировочному покеру

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

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

Узнайте, как провести успешное совещание по планировочному покеру.    

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

• Выберите пользовательскую историю. 

• Обсудите её с командой, в том числе то, что с ней связано и как выглядит успех. 

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

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

• Повторяйте этот процесс, пока не назначите стори поинты всем заданиям в бэклоге продукта. 

• Используя матрицу баллов, определите, сколько заданий ваша команда может выполнить в предстоящем спринте.

Совет. Планируйте сеансы планировочного покера после того, как команда о��ределит приоритеты в бэклоге и до начала спринта. Сессии планирования могут занимать от двух до четырёх часов (и ваша первая сессия, скорее всего, займёт больше времени), поэтому планируйте соответствующим образом. 

5. Планирование и выполнение спринта 

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

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

6. Постоянно совершенствуйте оценки

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

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

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

Как использовать стори поинты в проектах Agile

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

Чтобы лучше понять, что такое стори поинты, давайте рассмотрим, как их использовать в рамках фреймворка Agile:

• Сначала напишите пользовательскую историю для каждой желаемой функции. Пользовательские истории следуют формату «Как [персона], я хочу [цель], чтобы [результат или выгода]».

• Добавьте пользовательские истории в бэклог продукта. 

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

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

• Выполните спринт. 

Пример: Допустим, ваша история пользователя: «Как пользователь, я хочу иметь возможность отправлять отзывы и вопросы через сайт, чтобы лучше понимать функции продукта». Вы присваиваете этой пользовательской истории балл, который, по вашему мнению, соответствует объёму усилий, необходимых для её выполнения. Затем можно разбить эту историю на более мелкие задания, например определение объёма работ и дизайн формы обратной связи, написание кода для формы, подготовка страницы и тестирование формы, а также публикация страницы. 

Преимущества использования баллов для пользовательских историй

Стори поинты не просто так считаются MVP среди методов оценки — они упрощают оценку трудозатрат и планирование спринта. Но это ещё не всё. Вот ещё несколько преимуществ использования стори поинтов в Agile:

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

• Учитывайте непредсказуемость и риск. Стори поинты в Agile учитывают такие элементы, как неизвестные и риск. Использование этих факторов в планировании исключает догадки из оценки, позволяя более точно определять объем усилий.

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

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

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

Эффективная оценка с помощью story point с владельцем продукта 

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

Чтобы эффективно сотрудничать с владельцем продукта во время оценки Story Point:

• Приглашайте владельца продукта на совещания по оценке и планированию покерных сессий.

• Попросите владельца продукта уточнить требования, функциональность и ответить на вопросы.

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

• Убедитесь, что владелец продукта понимает концепцию стори поинтов и относительного размера.

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

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

Как избежать распространенных ошибок при оценке с помощью баллов

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

Использование неотносительных баллов 

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

Приравнивание баллов истории к часам 

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

Непоследовательная оценка с помощью стори поинтов

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

Чрезмерное внимание к точности 

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

Неспособность учиться на прошлых оценках 

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

Управляйте планированием спринтов и стори поинтами с помощью шаблонов

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