Что такое скорость в Scrum?

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

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

Пример скорости Scrum

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

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

Шаг 1 – Рассчитать скорость первой итерации (спринта)

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

Агильная команда начала итерацию, планируя завершить Историю A и Историю B, оцененные в 2 балла, и Историю C, оцененную в 3 балла. В конце итерации История A и История B полностью завершены, но История C завершена только на 80%. Агильные команды обычно признают только два уровня завершения: 0% или 100%. Следовательно, История C не учитывается при расчете скорости, и скорость для этой итерации составляет 4 балла.

Шаг 2 – Использовать скорость для оценки количества необходимых итераций

После понимания скорости из Шага 1 команда может рассчитать (или скорректировать) оценку того, сколько времени потребуется для завершения проекта на основе оценок оставшихся пользовательских историй, предполагая, что скорость в будущих итерациях останется приблизительно одинаковой. Это обычно точное предсказание, даже если оно редко бывает точным.

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

Связь между скоростью и баллами пользовательских историй в Scrum

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

Как связать скорость с количеством очков истории?

1. Команды часто используют «скорость» как показатель производительности, чтобы точно сообщить внешним лицам, насколько быстро работает команда Scrum.
2. Если оценки количества очков истории остаются стабильными на протяжении всего проекта, имеет смысл использовать очки истории для представления «скорости».
3. Если стабильность сохраняется не только внутри команды, но и между командами, а также на уровне всей компании, это позволяет измерять производительность и сравнивать результаты работы команд.
4. Если значения очков истории остаются стабильными, их можно использовать в качестве ориентира для планирования релизов. Позже можно оценить возможные сроки.

Как назначить очки истории пользовательской истории?

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

Существует два типа шкал, используемых для создания оценок очков истории:

• Линейная шкала (1, 2, 3, 4, 5, 6, 7, …)
• Последовательность Фибоначчи (0.5, 1, 2, 3, 5, 8, 13, …)

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

Пользовательская история Очки истории

Как более точно оценить скорость?

В Scrum скорость помогает понять, сколько времени требуется команде для завершения бэклога продукта. Однако обычно требуется несколько спринтов, чтобы команда достигла более стабильной скорости. Чтобы более точно оценить скорость команды, можно использовать данные о предыдущих отслеживаниях. Это позволит более точно предсказать, сколько историй команда сможет завершить в одном спринте. Для целей прогнозирования следует использовать среднее значение скорости последних трёх или четырёх спринтов.

Предположим, что новая команда Scrum планирует завершить 41 очко истории в первом спринте. В итоге они завершили только 38 очков истории и перенесли 6 очков истории на следующий спринт. Таким образом, их скорость составляет 38, как показано ниже:

Скорость Scrum

Средняя скорость на основе отслеживания предыдущих спринтов

Как уже упоминалось, команды не должны включать частично завершённую работу в скорость. Учитываются только пользовательские истории, отмеченные как «Готово», даже если остаётся небольшая часть задачи.

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

Теперь новая команда продолжает разработку с первого до четвёртого спринта. Количество очков истории, завершённых в каждом спринте: 38, 29, 38 и 39. Средняя скорость после четырёх спринтов составляет 36, как показано ниже:

Скорость Scrum по спринтам

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

График скорости

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

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

На основе приведённого выше примера график скорости показывает объём работы, завершённой командой Scrum в каждом из четырёх спринтов:

График скорости Scrum