Модель оценки бэклога, на выходе с которой вы получаете приоритизированный список, где первый элемент — самый простой в реализации, но при этом и самый ценный с точки зрения бизнеса. Определяется четырьмя факторами:
Для каждого элемента бэклога по этим факторам вычисляется приоритет по формуле:
WSJF = (User-Business Value + Time Criticality + Risk Reduction) / (Job Duration)
Список всего, что предполагается сделать в продукте. В идеале, это должен быть приоритизированный список: задач, инициатив, гипотез, пользовательских историй, багов, улучшений и прочих требований к продукту. Если ваш бэклог приоритизирован на 2-4 итерации вперед, то у вас достаточно приоритизированный бэклог.
Техники декомпозиции крупных элементов бэклога продукта (требований к продукту) на более мелкие элементы:
Критерии того, что задача/user story считаются завершенными. Т.е. это «фильтр на выход» (тогда как критерии подготовленности — «фильтр на вход» в разработку).
Например:
Команда определила для себя следующие DoD для задач, которые она планирует отправить в релиз программного продукта:
Критерии, которые определяют, что задачу/user story можно взять разработку. Т.е. это «фильтр на вход» (тогда как критерии готовности — «фильтр на выход» из разработки).
Например:
Команда устанавливает следующие DoR для входящих задач по разработке программного продукта:
Другими словами, пока данные критерии не будут выполнены, команда не начнет писать код.
Условия того, что задача/user story считается выполненной с точки зрения конечного пользователя. Другими словами, успешно выполняются пользовательские сценарии использования данного функционала.
Например, критерий приемки функционала «Счетчик невыполненных задач»:
Когда по задачам пользователя наступает deadline, то он получает push-уведомление о просроченной задаче. Открывая это уведомление, пользователь видит счетчик просроченных задач, т.е. видит общее количество таких задач.