OnAgile Learning Hub 💎

2 хороших способа приоритизации элементов бэклога

Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.

Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.

Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.

Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.

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

- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.

Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.

- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.

- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.

Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.

Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.

Подробно об этом методе читайте в блоге.

А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)

www.tg-me.com/us/OnAgile Learning Hub /com.agilethinking/215

2.7K viewsOlga, edited  Oct 18, 2021 at 07:55

2 хороших способа приоритизации элементов бэклога

Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.

Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.

Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.

Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.

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

- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.

Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.

- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.

- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.

Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.

Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.

Подробно об этом методе читайте в блоге.

А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)

BY OnAgile Learning Hub 💎