Чтобы понять, сколько и каких требований можно поместить в релиз или итерацию, необходимо их оценивать. Вы можете оценивать трудоёмкость или сложность требований. Единицы измерения (часы, Story Points) настраиваются в методологии проекта.
Чаще всего команды используют одну из простых методик: оценку в идеальных часах или оценку сложности в абстрактных единицах (попугаях). Идеальным час назван потому, что в работе постоянно возникают утечки времени на помощь коллеге, чай, обсуждение и т.п. Так что в день у каждого обычно есть 5-6 идеальных часов, а не 8. Такая оценка годится, если над задачей будет работать один человек, используется предыдущий опыт, либо требования достаточно подробные. В других случаях такая оценка будет крайне неточной, поэтому используют альтернативный метод - оценку в абстрактных единицах, например, размерах или Story Points (сокращенно SP). Это абстрактные величины, характеризующие сложность задачи (пользовательской истории).
Самым простым вариантом оценки сложности являются размеры футболок: X, L, M, S. Такая оценка быстрая, грубая, но позволяет показать возможности команды и ранжировать задачи по их сложности, например, с целью приоритизации - сделаем сначала простые и важные, потом сложные и важные и т.д.
Более точную оценку позволяют получить Story Points. Поскольку сами по себе они абстрактные, то оценку ведут по шкале, отражающей возрастание сложности задач. Чтобы построить такую шкалу использовали исследования, в которых показано, что мы различаем сложное от еще более сложного, когда их оценка отличается примерно на 160% - 170%. Поэтому для оценки в SP используют шкалы последовательности Фибоначчи (1, 2, 3, 5, 8, ...) или степени двойки (1, 2, 4, 8, 16, ...). Какую из них выбрать?
Чем выше сложность задачи, тем выше неопределенность и больше погрешность, поэтому эффективно можно использовать несколько начальных элементов шкалы, например, до 40. Все истории, которые получили оценку больше этого значения лучше декомпозировать на более мелкие истории, выяснить больше деталей. Так вот, шкала "степень двойки" более грубая и значит более простая в использовании, но очевидно, менее точная. На "степени двойки" стоит остановиться, если команда небольшая, в итерации мало историй, уровень неопределенности в требованиях невысок. В других случаях лучше воспользоваться Фибоначчи и организовать планирование итераций в формате "Покер планирования".
Если оценить сложность требования удается быстро, то это можно делать на систематической основе, путем периодического просмотра бэклога требований и указания оценки сложности непосредственно в бэклоге:
Если процесс оценки занимает больше времени, либо для этого необходимо привлечь нескольких участников процесса разработки, то можно выделить специальную стадию ЖЦ требований, например, "Уточнение" или "Оценка". Участники процесса могут собраться вместе, обсудить требование и результирующую оценку сохранить в карточке требования или доработки. Если собраться вместе нельзя, то можно записать свои оценки в соответствующих задачах, декомпозирующих требование:
Когда набор требований оценен, то несложно определить - помещаются ли эти требования в очередной релиз или итерацию. У релиза и итерации есть длительность. С учетом скорости команды - объема работы, выполняемого за день - можно определить ёмкость релиза или итерации. Используйте эти индикаторы при планировании состава релиза или итерации:
Более трудоемким способом приоритизации является метод WSJF. Приоритет требования (истории) вычисляется на основе формулы, которая зависит от таких критериев как:
Используйте соответствующие модули, например,
Система вычисляет Приоритет WSJF, по которому можно отсортировать строки. Сверху размещаются требования с наибольшей ценностью для клиента и менее трудозатратные. Единицы измерения коэффициентов соответствуют настройкам оценки трудоемкости в Методологии проекта.
Вы можете изменить расчет формулы, добавив собственные коэффициенты, либо введя новые критерии.