Василий Банников

1. Agile - это про то что люди должны договариваться. По тому надо не намёки делать, а говорить прямо и предметно.

2. Вот вы говорите, что вам нужно ТЗ. А зачем вам оно нужно?
Вам не понятна та постановка, которая описывается в карточках?
Есть неоднозначность?
Уже есть примеры, когда от этой неоднозначности пострадал продукт (например из-за необходимости переделывать)?

Или вам нужно не ТЗ, а виденье того, чем в итоге должен стать продукт?
Не понятно, для чего вообще все эти карточки перекладываются?
Если так, то, вероятно, вам нужно не ТЗ, а какие-то OKR-ы, чтобы можно было от них отталкиваться при составлении задач.

Возможно, произошла мискоммуникация между вами и заказчиком. Возможно, заказчик действительно ожидает от вас (команды) самостоятельности при составлении задач - по сути сочетание в себе и менеджера и аналитика.
Это нормально, но нужно этот момент тоже прояснить.

Я видел два варианта:
1й: Продолжать оценивать их в поинтах, обсуждайте на ретро, какие возникли сложности, почему ошиблись в оценке.
Со временем:
1. Сама по себе команда сможет точнее оценивать подобные задачи
2. Выработается механизм по преданалитике инженерных задач.

2й: вынести все инженерные задачи на канбан-доску и выделять разработчикам какое-то время на разгребание задач с неё.

Обсудите со своей командой оба варианта, дайте возможность предложить свои, проведите эксперимент.

Нет, никакая методология от такого не защищает.

Но можно немного снизить риски, если на более ранних этапах закладывать архитектуру, которую легко можно будет расширить/изменить.

Попробуйте youtrack.
Там и ldap есть и разные способы группировки досок. Возможно, это то что вам нужно.
Правда там ещё сложнее должно быть.
Интерфейс хз на сколько современный, но выглядит нормально.