Планирование спринта Scrum: что выбрать: Story Points или идеальные дни?

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

Что такое элемент невыполненной работы по продукту?

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

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

Характеристики хорошего бэклога продукта

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

1. Подробно надлежащим образом

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

2. Возникновение

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

3. Приблизительно

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

4. Приоритет

Несмотря на то, что невыполненная работа по продукту представляет собой список PBI с приоритетом, не все элементы должны подвергаться тщательной расстановке приоритетов. Если элемент запланирован к выпуску 2 или 3, может быть расточительно выделять время и ресурсы на раннее определение приоритетов, поскольку многие аспекты нашего проекта могут измениться. Как правило, вы должны стараться ограничивать свои усилия по расстановке приоритетов элементами, запланированными для текущего выпуска.

Концепции оценки PBI

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

• Оценивать всей командой. Вся команда должна участвовать в процессе оценки, так как это один из принципов соединение Scrum с Agile, его методологический родитель. Владелец продукта должен присутствовать, чтобы описать PBI и предоставить любые необходимые разъяснения, однако окончательную оценку должна предоставить команда разработчиков, поскольку именно они будут выполнять работу.
• Оценки не являются обязательствами. Если к оценкам относиться как к обязательствам работников, то в большинстве случаев работники будут переоценивать усилия, чтобы не нарушить сроки и не понести штрафные санкции. По этой причине оценки должны оставаться именно оценками.
• Точность важнее точности. Мы должны стремиться к тому, чтобы оценки были точными, но не слишком точными. Другими словами, они должны соответствовать фактическим усилиям, которые потребуются для выполнения этого пункта. Стремление к точности часто приводит к трате слишком большого количества ресурсов, но не дает особых преимуществ.

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

Что такое Story Points?

Story Points измеряют величину PBI, принимая во внимание размер элемента, а также его сложность. Некоторые элементы могут быть не такими большими, но очень техническими и сложными, в то время как другие большие, но довольно тривиальные. Эти истории представляют разные проблемы, однако они потребуют одинакового количества усилий. Поэтому необходимо учитывать оба этих параметра. Конечная цель стори-пойнтов — дать возможность сказать: «Если история 1 имеет два сюжетных очка, то история 2 — восемь», подразумевая, что история 2 в четыре раза больше истории 1.

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

Плюсы историй

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

Минусы историй

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

Что такое идеальные дни?

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

Плюсы идеальных дней:

• Он интуитивно понятен и конкретен.
• Клиенты и заинтересованные стороны понимают это легче, чем сюжетные точки.

Минусы идеальных дней:

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

Что лучше: Story Points или Ideal Days?

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

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

:::информация Также опубликовано здесь.

:::