Срок экспериментальной ветки я бы задавал как дату решения, а не обещание влить прототип в основную базу.

Условный пример: пробуем другую библиотеку, чтобы снизить расход памяти при пакетной генерации PDF. Короткий документ выглядит хорошо, длинная таблица ломается, замера на большой пачке ещё нет. Обещание «к пятнице смержим» здесь подталкивает защищать уже написанный код, хотя подход ещё проходит проверку.

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

Если польза подтверждена, перенос стоит оценить отдельно: что сохраняем из прототипа, что переделываем под актуальную базу и как проверяем совместимость. Если данных мало, можно согласовать следующий конкретный тест и новый срок. Если подход не подошёл, достаточно сохранить воспроизводимую проверку и вывод. Поставлять неудачную реализацию ради оправдания затрат не нужно.

Зависимость релиза тоже должна быть явной. Если без этой замены выпуск невозможен, у неё должны быть владелец и согласованный срок. Если возможен, остальная работа не обязана ждать экспериментальную ветку.

В назначенный день важно решить, что делать дальше. Обязательного merge в списке результатов исследования нет.