Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
Enterprise Agile Russia
HR
Kanban
KPI
LeSS
Nexus
OKR
OKR Russia
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

Стори Поинты (Story Points)

Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.


Ниже — перевод статьи Джеффа Сазерленда Story Points: Why are they better than hours? с сайта Scrum Inc.

Чем Стори Поинты лучше человеко-часов?

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

Точность оценок

Последние исследования от Microsoft показывают, что оценка по agile демонстрирует поразительную точность в сравнении с традиционными методами оценки проектов. Подробнее об этом исследовании вы можете почитать здесь:
Scrum + Engineering Practices: Experiences of Three Microsoft Teams

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

Успешность проектов

Давайте посмотрим на последние данные по неуспешным проектам. Глобальная финансовая система рушится, и вместе с этим растет процент провальных проектов в IT. Недавно было проведено одно интересное исследование: консалтинговая фирма Standish Group собрала данные об успешности нескольких десятков тысяч проектов, стартовавших за последние десять лет. Аналитика от Standish Group показывает, что процент успешности agile-проектов в три раза превышает успешность проектов, ведущихся традиционным образом. Джим Джонсон рекомендует использование agile-практик на всех без исключения проектах.

Также последние исследования Forrester Group говорят, что традиционные метрики управления проектами приводят IT-департаменты к неудачам.

Разрыв между оценками сроков и реальностью

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

Дело в том, что для планирования релиза критичным является постоянство пользовательских историй. Три стори поинта сегодня — это те же три стори поинта в следующем году, и для Владельца Продукта эти стори поинты являются измеримой частью релиза продукта. Тогда как количество часов для завершения истории зависит от того, кто ее делает и в какой день. Эти показатели меняются ежедневно. Диаграмма Ганта предполагает фиксированное количество часов на задачу для какого-то гипотетического человека (который зачастую не является фактическим исполнителем задачи) и заведомо известные зависимости (которые на самом деле непрерывно меняются). Исследование восьмидесяти мультимиллионных проектов, проведённое в GSI Commerce (ими сейчас владеет eBay), показало, что лучшие эксперты в компании оказались неспособными правильно оценить время выполнения проекта людьми, которые действительно его реализовывали.

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

Вариабельность оценок

Исследование, проведенное Rand Corporation еще в 1940х годах, очевидно продемонстрировало неспособность людей точно проводить оценку в часах, и практический опыт постоянно подтверждает этот факт. Вместо часов для оценки рекомендуется использовать метод «Дельфи», известный в разработке программного обеспечения как техника Wide Band Delphi. Аналогичная техника используется agile-командами и носит название Покер планирования.

Интересные данные по личной продуктивности разработчиков пришли из Йельского Университета. Лучшему разработчику на проекте требуется один час, чтобы сделать задачу, в то время как худшему требуется 10 часов (в рамках его проекта) или даже 25 (если проект незнакомый). Для команд эта разница еще на порядок больше. Данные, опубликованные Ларри Путнемом (Larry Putnam) показывают, что задача, на которую наиболее продуктивной команде требуется час, может превратиться в 2000 часов для наименее продуктивной команды.

Процесс оценки в стори поинтах дает лучшую точность, чем оценка в часах, за счет меньшей вариативности стори пойнтов. Одна компания 5го уровня CMMI определила, что оценка в стори поинтах сокращает время оценки на 80%, что позволяет оценивать больше фич и отслеживать их, в сравнении с каскадной моделью. Другая компания из телеком индустрии заметила, что оценка с помощью стори поинтов и Покера планирования была не только в 48 раз быстрее, чем практики каскадной оценки, но и дала более точные результаты.

Мера прогресса

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

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

Что действительно является важной метрикой, так это количество стори поинтов, которую команда может поставить за календарный период. Число поинтов за спринт — это производительность команды (velocity). И несмотря на то что все оценки происходят в стори поинтах, Владелец Продукта делает план релизов на основании производительности команды и корректирует его, если эта производительность меняется.


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

Jeff Sutherland, 2013

Другие термины

Диаграмма Сгорания Работ Спринта (Sprint Burndown Chart)

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

Узнать больше

Критерии Готовности к Разработке (Definition of Ready)

Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.

Узнать больше

Критерии Приемки (Acceptance Criteria)

Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.

Оценка (Estimation)

Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.

Производительность команды [Скорость](Velocity)

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

Узнать больше