Привет!  Ниже по тексту предлагаю ознакомится с подходом, который я применяю для определения функциональности, которая должна войти в MVP для продуктов с достаточной степенью определенности в бэклоге. Если зайдет, распишу подробнее. Прошу не судить строго, но буду рад конструктивной критике.  Для всех кто готов мириться с сыроватостью идеи, добро пожаловать под кат) Задача определения функциональности MVP появляется еще на этапе планирования разработки продукта и требует обновленного решения по мере развития продукта, вплоть до окончания разработки MVP.  Сама концепция MVP предполагает как можно более быструю доставку продукта конечным пользователям для получения от них обратной связи, однако собственники продуктов (Product Owner) зачастую превышают минимальную функциональность стремясь сделать продукт лучше, что влечет за собой срывы сроков, превышение бюджетов, а в худших случаях и вовсе развитие продукта в неправильном направлении.  Для нивелирования вышеупомянутых рисков предлагается использовать конкретный подход, основанный на математических принципах, для регламентирования процесса определения функциональности MVP.  Критериями для задачи определения MVP функциональности являются критерии, взятые из методологии WSJF а также дополнительная декомпозиция Job Duration на составляющие: Оценка выполняется с помощью числового ряда Фиббоначи от 1 до 21. (1, 3, 5, 8, 13, 21). Данный способ оценки универсален с точки зрения использования его при оценке задач в Story Points при планировании, и для групповой оценки критериев также возможно использования Scrum-poker.  Также, оценка с помощью ряда Фиббоначи обусловлена тем, что каждый шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 и 21 Story Points.
Оценки по критериям из группы Jobs Duration выполняются командой разработки, а оценки по группе критериев Cost Of Delay – только с привлечение бизнес-заказчика и Владельца Продукта.  Итогом оценки будет матрица следующего вида: Многокритериальная оптимизация, или программирование (англ. Multi-objective optimization) — это процесс одновременной оптимизации двух или более конфликтующих целевых функций в заданной области определения. Наиболее простым способом решения задачи многокритериальной оптимизации является метод Свертывание критериев, для сведения многокритериальной оптимизации к однокритериальной. Метод свертывания критериев предполагает преобразование набора имеющихся частных критериев в один суперкритерий. Т. е. мы получаем новый суперкритерий, который является функцией от частных критериев. Для свертывания критериев в суперкритерий необходимо также проставить весовые коэффициенты: Для бизнес критериев и критериев разработки необходимо устанавливать отдельные весовые коэффициенты.  Таким образом свертывание критериев будет выглядеть следующим образом: Cost Of Delay = User-Business Valuek11+ Time Criticalityk12+ Risk Reductionk13+ Opportunity Enablementk14
Jobs Duration = Job Durationk21+ Job Complexityk22+ Job Cost*k23
K11+K12+K13+K14=1
K21+K22+K23=1
Общий критерий оптимизации (Mutual Criteria) = Cost of Delay/Jobs Duration.  Таким образом мы получаем матрицу следующего вида: Итоговой целевой функцией является Максимизация по Mutual Criteria.  ABC-анализ — метод, позволяющий классифицировать задачи по степени их важности. Этот анализ является одним из методов рационализации и может применяться в сфере деятельности любого предприятия. В его основе лежит принцип Парето — 20 % всех усилий дают 80 % результата. По отношению к ABC-анализу правило Парето может прозвучать так: 20% функциональности позволяет покрыть 80 % потребностей пользователей.  ABC-анализ — анализ бэклога (набора Features) путём деления на три категории:  А — наиболее ценные, 20% — от количества; 80% — удовлетворения потребностей
В — промежуточные, 30% — от количества; 15% — удовлетворения потребностей
С — наименее ценные, 50% — от количества; 5% — удовлетворения потребностей Группа А является группой функциональности входящей в MVP.  По сути, ABC-анализ — это ранжирование бэклога по разным параметрам. Результатом АВС анализа является группировка объектов по степени влияния на общий результат.  АВС-анализ основывается на принципе дисбаланса, при проведении которого строится график зависимости совокупного эффекта от количества элементов. Такой график называется кривой Парето, кривой Лоренца или ABC-кривой. Таким образом, 20% функциональности, закрывают 80% потребностей. Исходя из данного принципа, производим АВС анализ для бэклога, для определения MVP.  Для этого: Важное замечание: Необходимо также учитывать CORE функциональность. Группа «А» может совпадать c CORE, но в случае не совпадения, результаты АВС анализа должны быть дополнены Core функциональностью.  CORE – функциональность – это основа функционирования продукта, которая состоит из функциональности, без которой функционирование продукта невозможно. (Например, авторизации).  Применение данной методики для определения набора Features для MVP обеспечивает обоснованный выбор рационального количества задач, необходимых к выполнению для скорейшего достижения MVP. Product Manager