​​Как формировать бэклог продукта, если ресурсы ограничены? Один из подходов. Часть 2.
(48 секунд)

Итак, в качестве подготовки к описанию подхода формирования бэклога, необходимо было чётко сформулировать: из чего будет состоять бэклог.

1️⃣ Выстроенная иерархия в бэклоге. В данном случае предлагалась следующая-классическая:

Epics → Features → US (как уровень бэклога, а не как формат описания)

2️⃣ Определяем, что означает каждый уровень (да, далеко не все понимают, чем эти уровни отличаются).

В рамках проекта из кейса было предложено сильно упрощённое описание, чтобы никого не путать:

Epics — ключевые сущности (объекты)) = существительные (например: Активности)

Features — действия, которые можно делать с сущностями + касающиеся сущностей = глаголы (например, Создание сущности)

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

Важные комментарии в отношении US, которые мы давали:

1️⃣ Наша цель формирования US — посмотреть, что мы закрываем потребности бизнес-ролей в рамках выделенных фич (потребности были выявлены на этапе глубинных интервью).

2️⃣ Наши US — высокоуровневые, и для передачи их в разработку будет необходимо их уточнять, сплитить и детализировать с помощью AC уже на этапе delivery.

В части 3 посмотрим уже на сам подход и на возражения, с которыми встретились.

——
Поддержать канал