2021-10-18 10:55:56
2 хороших способа приоритизации элементов бэклогаОбсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это
приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
-
Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
-
Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
-
Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория —
Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод —
Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы? Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
876 viewsOlga, edited 07:55
O
