Немного про Story Points
Не так давно, мы с одной командой перешли от оценки в часах к относительным оценкам сложности задач.
Решил напомнить, что такое эти Story Points и какие минусы имеет такая оценка.
Оценка задач в story points является одним из подходов к оценке сложности задач в Agile-разработке, особенно в методологии Scrum. Story points — это относительная мера сложности задачи, а не ее временной оценки.
Вот некоторые рекомендации по оценке задач в story points:
- Оцените сложность, а не время: Story points оценивают сложность задачи, а не ожидаемое время выполнения. При оценке учитывайте такие факторы, как техническая сложность, объем работы, риски и неопределенность.
- Используйте относительные меры: Story points являются относительными мерами, поэтому задачи оцениваются в сравнении с другими задачами. Обычно используется шкала от 1 до 10 или Фибоначчиева последовательность (1, 2, 3, 5, 8, 13 и т. д.) , где более высокие числа указывают на более сложные задачи.
- Используйте коллективное знание команды: Оценка задач должна быть коллективным усилием. Вовлеките всю команду разработки или реализации задачи, чтобы получить более точную оценку. Разные члены команды могут иметь разное понимание сложности задачи и могут внести ценное мнение.
- Используйте исторические данные: При оценке новых задач полезно обращаться к историческим данным и оценкам предыдущих задач. Если у вас есть опыт выполнения похожих задач в прошлом, это может помочь вам в оценке сложности новых задач.
- Учитывайте внешние факторы: При оценке задач учитывайте внешние факторы, которые могут повлиять на сложность или время выполнения, такие как зависимости от других команд, доступность ресурсов или внешние ограничения.
Хотя оценка задач в story points имеет много преимуществ, есть и некоторые потенциальные недостатки, о которых стоит упомянуть:
- Отсутствие стандартизации: Story points не имеют жестких определений или единой шкалы оценки. Каждая команда может использовать собственную интерпретацию и шкалу, что может привести к разнообразию в оценках и затруднить сравнение между командами.
- Несоответствие между оценками и временем: Story points предназначены для оценки сложности задачи, а не для прогнозирования времени ее выполнения. Это может вызывать затруднения при попытке сопоставить story points с фактическим временем, особенно при установлении сроков или взаимодействии с другими командами или заинтересованными сторонами, которые ожидают более точных временных оценок.
- Субъективность и вариабельность: Story points зависят от субъективного мнения и оценки членов команды. Разные люди могут иметь разное понимание сложности задачи и по-разному оценивать ее. Это может приводить к вариабельности в оценках и усложнять планирование и прогнозирование.
- Отсутствие прозрачности для заинтересованных сторон: Story points являются внутренним инструментом команды разработки и могут быть сложными для понимания или интерпретации для стейкхолдеров, которые не знакомы с Agile-подходом и методологией Scrum. Это может создавать проблемы при общении о прогрессе проекта или при установлении ожиданий со стороны заинтересованных сторон.
- Ограниченная применимость: Story points лучше всего работают для оценки относительно небольших задач и итераций. При оценке крупных или сложных проектов может быть сложно справиться с масштабированием и точным представлением сложности.
Важно понимать, что эти недостатки не делают story points неполезными или неприменимыми, но важно быть осведомленным о них и уметь адаптироваться в соответствии с конкретными потребностями и контекстом команды разработки.
Так же нужно не забывать, что оценка в story points является предварительной и может измениться в процессе выполнения задачи, когда появляется более точная информация. Это необходимо для того, чтобы использовать story points в планировании и прогнозировании проекта.
Я бы добавил один нюанс к Story Point, который сделает их более понятными
Необходимо добавить параметр
Общая сложность для команды за итерацию
И тогда всё станет понятно
Команда найдёт потолок сложности (будет понятно куда расти и стоит ли)
Владелец продукта поймёт потенциал команды (что можно и что возможно)
Я больше люблю раскладывать и смотреть сложность по исполнителям еще. Смотреть на всю команду можно, только, когда команда полностью взаимозаменяемая и любой исполнитель может взять любую задачу.
Подскажите пожалуйста, а фича листы для пресейла как оцениваете в часах или сторипойнтах?
Я сейчас в продукте :)
Но раньше, когда был в коммерческом аутсорсе, оценивали фичи в кварталах/месяцах/неделях. Какие SP на пресейле))
Заказчику нужна дата выкатки фичей в прод.