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

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

Длинные непрерывные блоки могут быть полезны для сложных задач. Инцидент или узкое окно миграции тоже могут оправдывать рывок. Универсальное ограничение длительности сессии здесь мало поможет.

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

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

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