Стори-поинты в Scrum: что это такое и как оценивать

Что такое стори-поинты?

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

Ключевое слово — относительная. Людям плохо удаётся сказать, сколько часов что-то займёт, но вполне хорошо — что «это примерно вдвое больше, чем то». Стори-поинты используют эту сильную сторону. Сами по себе числа ничего не значат; они имеют смысл только в сравнении с другими элементами, оценёнными той же командой.

Оценка в стори-поинтах обычно отражает три вещи:

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

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

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

Являются ли стори-поинты частью Scrum?

Нет. Руководство по Scrum (редакция 2020 года, по-прежнему актуальная официальная версия) говорит, что за оценку элементов бэклога продукта отвечают разработчики, которые будут выполнять работу, и что владелец продукта может помочь им понять компромиссы. Как именно оценивать, в нём не сказано. Стори-поинты, как и пользовательские истории, — дополнительная практика, которую выбирают многие Scrum-команды.

Стори-поинты выросли из экстремального программирования (XP) в конце 1990-х и начале 2000-х годов. Рон Джеффрис, один из основателей XP, объяснял, что сначала команды оценивали в «идеальных днях» (сколько заняла бы работа у пары без прерываний), а затем умножали на коэффициент нагрузки, чтобы получить календарное время. Поскольку заинтересованным сторонам идеальные дни казались запутанными, команда стала называть их «поинтами». В статье 2019 года Джеффрис написал, что, возможно, это он предложил название и что теперь он «сожалеет» о том, как часто поинты используются неправильно, но при этом сказал, что командам, которые находят их ценными, стоит продолжать.

Эта история объясняет и сильные стороны, и критику стори-поинтов, о которой мы поговорим ниже. О том, как Scrum устроен в целом, см. что такое Scrum.

Почему Scrum-команды используют стори-поинты

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

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

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

Стори-поинты и часы

Можно ли перевести поинты в часы? Надёжно — нет. Майк Кон из Mountain Goat Software, много писавший об оценке в Agile, утверждает, что каждому значению поинтов соответствует диапазон часов, а не фиксированное число, и что этот диапазон различается у разных людей. Элемент в 3 поинта может занять у старшего разработчика полдня, а у новичка — два дня; и оба всё равно могут согласиться, что это 3. Фиксация «1 поинт = 4 часа» просто превращает поинты обратно в часы с лишним шагом.

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

Шкалы стори-поинтов

Большинство команд используют шкалу с растущими интервалами между числами. Интервалы отражают то, что более крупные элементы несут больше неопределённости, и избавляют команду от споров о разнице между 6 и 7.

В колоды для покера планирования часто добавляют специальные карты: 0 для пустяковой работы, ? для «пока не могу это оценить» и чашку кофе для «давайте сделаем перерыв». ? обычно означает, что элемент нуждается в уточнении или спайке, прежде чем кто-либо будет его оценивать.

Пример эталонной таблицы

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

Как оценивать в стори-поинтах: пошагово

Вот практичный способ внедрить стори-поинты в Scrum-команде. Шаги 1–3 — разовая настройка; шаги 4–8 становятся рутиной.

1. Выберите эталонную историю. Возьмите недавно завершённый элемент, который все помнят, не крошечный и не огромный, и выполненный примерно так, как ожидалось. Присвойте ему значение, часто 2 или 3.
2. Добавьте ещё один-два ориентира. Явно меньший элемент (1) и явно больший (5 или 8) облегчают сравнение. Вместе они образуют вашу базу.
3. Согласуйте шкалу и правила. Выберите шкалу наподобие Фибоначчи, определите максимально допустимый размер для спринта и договоритесь, как будете поступать с багами и спайками.
4. Уточняйте, прежде чем оценивать. В уточнение бэклогавладелец продукта объясняет каждый элемент, а команда проясняет критерии приёмки. Оценка неясных элементов — пустая трата времени.
5. Оценивайте вместе. Каждый разработчик формирует мнение, сравнивая элемент с эталонными историями, затем все показывают оценки одновременно, например с помощью покера планирования.
6. Обсуждайте расхождения, а не средние значения. Если оценки разбросаны от 2 до 8, назвавшие самую высокую и самую низкую объясняют свои рассуждения. Часто кто-то знает то, чего не знают другие. Проголосуйте снова; как только оценки сблизились, быстро договаривайтесь.
7. Разбивайте всё слишком крупное. Если элемент оказывается выше согласованного максимума, разбейте его на меньшие, но по-прежнему ценные части, прежде чем он попадёт в спринт. Наше руководство по эпикам, историям и задачам показывает, как это сделать.
8. Фиксируйте и пересматривайте. Укажите оценку в элементе. Раз в несколько спринтов оглядывайтесь назад на ретроспективе: действительно ли элементы, оценённые в 5, похожи друг на друга? Корректируйте эталонные примеры, а не прошлые оценки.

Planning Poker в Scrum

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

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

В Scrum голосуют Разработчики . Владелец продукта объясняет элемент, Scrum-мастер фасилитирует, но ни один из них не выкладывает карту, если сам не выполняет работу. Удалённые команды могут использовать простой онлайн-инструмент для покера планирования или функцию оценки в своём ПО для управления проектами.

О других техниках, таких как аффинитивная оценка, метод корзин и оценка в размерах футболок, см. наше руководство по оценке в Agile и шкале Фибоначчи.

Разобранный пример: оценка бэклога

Команда, создающая систему онлайн-бронирования, использует «Клиент может отменить бронирование из письма с подтверждением» = 3 поинта в качестве эталонной истории. При уточнении она оценивает следующие элементы так:

Элемент с депозитом на 13 поинтов слишком велик, чтобы надёжно завершить его за один спринт, поэтому команда разбивает его на «Оплатить депозит картой (основной сценарий)», «Вернуть депозит при отмене» и короткий спайк по тестовой среде платёжного провайдера. Элемент с SMS получает 8 в основном из-за неопределённости; когда команда однажды поработает с SMS-сервисом, аналогичные элементы, вероятно, станут меньше.

Обратите внимание, что команда ни разу не упоминает часы. Каждое число — это сравнение с эталоном в 3 поинта.

Кто и когда оценивает в стори-поинтах

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

Оценивайте только на несколько спринтов вперёд. Элементы в глубине бэклога, скорее всего, изменятся, поэтому давайте им грубые размеры футболок и оценивайте в поинтах как следует, когда они приблизятся.

От стори-поинтов к планированию спринта и прогнозам

Стори-поинты становятся полезными, когда их складывают. Сумма поинтов элементов, полностью доведённых до «Готово» за спринт, — это скоростикоманды. Элементы, не доведённые до «Готово», не приносят ничего, как бы близки к завершению они ни были; именно это делает скорость честной.

Использование скорости при планировании спринта

Допустим, за последние три спринта команда поставила 28, 33 и 30 поинтов. Её средняя скорость — около 30 поинтов. В следующем спринте один из шести разработчиков будет в отпуске все две недели, поэтому команда рассчитывает примерно на пять шестых обычной загрузки: около 25 поинтов. На планировании спринта она берёт элементы сверху бэклога, пока не наберёт около 25 поинтов, соответствующих связной цели спринта, и на этом останавливается.

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

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

Если до релиза осталось 150 поинтов оценённой работы, а скорость колебалась от 25 до 33, релиз, вероятно, займёт от 5 до 6 спринтов (150 ÷ 33 ≈ 4,5 и 150 ÷ 25 = 6). Всегда указывайте диапазон и обновляйте его каждый спринт по мере изменения скорости и бэклога. диаграмма скорости позволяет легко показать тенденцию.

Баги, спайки и незавершённая работа

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

• Баги, найденные в работе текущего спринта, являются частью завершения этого элемента. Не оценивайте их отдельно; элемент не готов, пока они не исправлены.
• Баги из более ранней работы или из эксплуатации — это новые элементы бэклога продукта. Многие команды оценивают их в поинтах, как любые другие элементы, чтобы трудозатраты отражались в скорости; другие оставляют для них небольшой запас без оценки. Подходит любой вариант при условии последовательности.
• Спайки (исследования с таймбоксом для снижения неопределённости) обычно ограничиваются таймбоксом, а не оцениваются в поинтах, или получают небольшое фиксированное значение. Их результат — знания, позволяющие команде оценить реальный элемент.
• Технический долг работу можно оценивать в поинтах, как функции, чтобы она на равных конкурировала за место в бэклоге. См. технический долг в Scrum.
• Незавершённые элементы возвращаются в бэклог продукта. Не делите поинты между спринтами; переоцените оставшуюся работу, если она изменилась, и засчитайте её, когда она будет готова.

Типичные ошибки со стори-поинтами

Скорость — один из нескольких полезных показателей.

Критика стори-поинтов и альтернативы

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

Если стори-поинты не помогают вашей команде, рассмотрите альтернативы:

• Подсчёт элементов. Если команда разбивает работу на небольшие элементы примерно одного размера, простой подсчёт элементов, завершённых за спринт, часто прогнозирует не хуже поинтов и не требует встреч по оценке.
• Пропускная способность и вероятностное прогнозирование. Используйте историческую пропускная способность и моделирования Монте-Карло для получения прогнозов с уровнем уверенности, например «с вероятностью 85% к 14 марта».
• Оценка в размерах футболок. Грубых размеров S/M/L достаточно для решений на уровне дорожной карты и эпиков.
• #NoEstimates. Движение, которое вообще ставит под сомнение детальную оценку и сосредоточено на нарезке работы на мелкие части и прогнозировании по потоку. См. планирование в Kanban о том, как планируют команды, работающие в потоке.

Каким бы методом вы ни пользовались, требование Руководства по Scrum остаётся неизменным: разработчики оценивают работу так, чтобы это помогало им планировать спринты, а владельцу продукта — принимать решения.

Шаблоны и инструменты для стори-поинтов

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

Большинство Scrum-инструментов включают поле оценки и отчёты о скорости. Jira имеет встроенную оценку в стори-поинтах на Scrum-досках и в отчётах, поэтому популярна у команд разработки ПО.

Бесплатные шаблоны по этой теме

Все шаблоны

Частые вопросы