Ну и куча итераций на стадии разработки этой постановки

ну... то есть у вас биг дизайн апфронт таки

какая разница - в ТЗ он задокументирован или в макетах и проекте

а это уже нифига не гибкое.
А то, что у вас спринты мешаются и надо бы вместо них вехи - об этом уже писали.
Наделайте себе вех "примерно по 2 недели" и в итоге вы будете поставлять готовые вехи, а не "что успели за 2 недели"
Если у вас поделено примерно по 2 недели, то неуспевание на пару дней - это гонг, а не "слив спринта"
да и цели выдумывать не надо

Тут логично, тогда вопрос, а ведение вех где-то автоматизировано?

Джировские спринты, которые используем, выполняют эту функцию

да ну и пусть у вас вехи будут в Джире спринтами

хоть горшком назови, только в печку не ставь

просто не надо их через 2 недели закрывать, а когда все сделали.

Скорее всего, у нас трудности перевода. И используем мы эти самые вехи, только называем их спринтами

ага
просто под спринтом все привыкли понимать фиксированное по времени, как в скраме (ну или это лично мои заморочки, как сейчас скажут уважаемые коучи - потому что книжек мало читал)

Можно рассмотреть скрам с позиции разделения птель обратной связи на КАК делать и ЧТО делать. В вашем случае, петли направленные на ЧТО, вероятно, вы использовать не будете. Но остальные - вполне. Да, это будет не скрам, но вам же все равно.

Так же вы писали, что заказчику нужны готовые подсистемы, а не мелкие участки автоматизации бизнес процессов. Но это ведь речь про заказчика, а не про конечного пользователя. Если вы готовы после поставки подсистемы за раз принять большой объем обратной связи и не считаете это потерей времени, то без проблем. Но, с другой стороны, вам нужна обратная связь от конечных пользователей, в том числе. А они, может быть и не против её дать. Так можно по-раньше адаптировать ЧТО. А заказчику уже выкатить с тем посылом что мол вот смотрите... мало того что подсистема готова, так она еще и протестирована на ваших сотрудниках.

Спасибо! А про эти петли в гугле есть смысл почитать? Скажите, пожалуйста, подход так и называется «теория петель»?

То что я описал основано на гайде.
Прозрачность, инспекция, адаптация.
Прозрачность - видеть что происходит.
Инспекция - "тестировать на правильность" то что увидел.
Адаптация - изменять после "теста".
И заново.
Обычный цикл PDCA, по сути.
Ведь вся эта итеративность она нужна для адаптации. Вот и смотрите, есть ли возможность адаптироваться. Если есть возможность, то используете циклы. Если нет - можно просто работать )))

Вот такие петли на вскидку можно увидеть в скраме:
Ретроспектива - КАК вообще.
Дэйли - КАК достигнуть цели спринта.
Ревью спринта - ЧТО.
Планирование - ЧТО И КАК.
Рефайнмент - ЧТО.
Скрам Мастер - КАК.

С распределением на ЧТО и КАК особо не парился... первое что в голову пришло написал.

Ну нет, обратная связь это единственный инструмент управления в скрам

Правда должен быть человек который должен знать как правильно делать... Где они его находят я не знаю
У меня такого обычно не было рядом

Что "нет"? Не понял чему ты возразил :)

Я для Жени писал

Обратная связь это процесс управления
Прада в скраме он самый дорогой, через готовый результат дорогих программистов
Но бюджет и скрам это несовместимые вещи

Ага, пожалуй

Хотя скрам не ограничивает PO в первоначальной проверке гипотез через рисование в тетрадке в клеточку.