Vitsliputsli

чтобы мне такого почитать про оценку времени вообще и про декомпозицию задач в частности?

Я бы посоветовал ничего не читать и не тратить впустую время. Оценка времени разработки никогда не бывает точной и с этим нужно смириться. Декомпозиция вещь хорошая, но тут теория вряд ли поможет, только опыт разработки.
Любая попытка более точной оценки - это устранение неопределенностей, для этого, например, разбивают на более мелкие задачи в которых точно уже известно что делать и кажется что все контролируешь. Но, оценка никуда не делась и она всегда строится на "похожих" задачах, которые уже делались. Только вот если мы говорим про нормальную разработку, то там это не работает, совсем... Если действительно похожая задача реализована, значит основной функционал уже есть и нужны только минимальные правки, а значит вторая задача будет стоить несравнимо меньше. Другой момент, действительно со стороны может показаться что есть похожие задачи и на них всегда тратится похожее кол-во времени, но в какойто момент времени окажется что следующая "похожая" обойдется в 10 раз дороже. Поэтому если где-то похожие задачи всегда стабильно стоят одинаково, то скорее там не разработка, а набор текста.
Если про правки "в сильно незнакомом коде", то даже не пытайтесь, здесь неопределенность зашкаливает. Такой код требует предварительно изучения, и не важно какая задача, она может решаться как добавлением 2 строчек, так и переписыванием всего и вся.
"возможно предварительно поисследовав", как только вы употребили слово исследование, никакие оценки здесь уже не применимы. Исследования не оценивают, на них выделяют время, когда время закончилось решают нужно ли еще время или бессмысленно копать в эту сторону.
Это все, конечно, несколько утрировано, но, на мой взгляд все что требуется со стороны разработчика (а я так понял вопрос именно с этой стороны) это просто давать оценку задачам, а затем обращать внимание на аспекты которые потребовали много времени, но которые упустили при планировании.

Confluence, обычно в нем ведут базу знаний, также там есть теги - labels.

Разумеется такие специалисты есть, не думаю, что сложно будет найти такие предложения. Есть 2 варианта - нанять менеджера (какой-нибудь кризис-менеджер работает около года, выстраивает процессы, затем уходит, т.к. стоимость его очень высока), и есть консультанты с различной стоимостью. 1 вариант лучше, т.к. в отличии от консультанта такой менеджер несет ответственность за то, что делает, т.к. он внутри. Консультант, даже дорогой, может сказать, что команда просто не точно, не полно выполняла его рекомендации (а это всегда можно сказать, к тому же команда может оказаться в ситуации, когда ей придется выбирать между положить силы на сомнительные рекомендации консультанта или выполнить план, при этом за провал плана команда по-прежнему несет ответственность). Я не видел хороших консультантов, даже дорогой консультант может начать все выстраивать по стандартным нормам, которым его обучали, на практике же, как вы правильно указали нужно выявлять слабые места и чинить их, а это сложнее, требует глубокого погружения и потому занимает гораздо больше времени. И, в конце концов, если полное болото, то всегда можно нанять обычного менеджера с опытом выстраивания процессов, но при этом и технический руководитель должен знать и уметь внедрять инновации, без этого в разработке никак.

Многие фронтендеры относятся к беку, как к некой обертке для работы с базой данной. Когда такие становится лидом команды и начинают диктовать свои требования беку, начинается ад, проект даже с простым беком превращается в нечто монструозное, разваливающиеся на ходу. Но, так как снаружи бек не виден, руководство считает, что дело в отдельных тупых бек-разработчиках, которые артачатся, не хотят работать и увольняются.
Судя по вашим фразам, вы скорее всего один из них. Так как уверены, что приложение - это то, что на фронте, что api - это хрень, которая завязана на отображении информации на фронте, что разработчики бека не нужны при разработке архитектуры и вообще пофиг, что они там делают, главное чтобы давали то, что хочет фронт.
Но, раз вопрос задан, значит сомнения вас посещают. Поэтому: приложение это не только фронт, а зачастую фронт это не самая сложная его часть. Бек - это не обертка над базой данных, и если вы поменяете значение в базе, это не значит, что к примеру, в потоковом вещании сменится кодек (вот, кому-то может и смешно, а мне в такой ситуации ни фига не было весело). С помощью API получают данные, поэтому не важно, что там у вас напроектировали дизайнеры, или как эти данные выводит фронт, API должен быть универсальным и не зависить от того как вы отображаете данные, поэтому, к примеру, бек может вам дать для получения данных несколько универсальных запросов, а не один специальный. В общем, все гораздо сложнее, и ваш вопрос как состыковать фронт и бек перерастает в вопрос как формировать архитектуру проекта, и как управлять командой.

Если у вас "четкое" разделение на фронт и бэк, значит, по сути у вас 2 технических проекта, взаимодействующих между собой. И у них не может быть одной и той же задачи, т.к. делают они разное.
Судя по остальному тексту, вы не декомпозируете задачи, отсюда и такие вопросы. Тогда, у вас 2 варианта, начать декомпозировать задачи на отдельные подзадачи, где будет отдельный исполнитель, можно прикинуть трудозатраты, указывать зависимости и т.п. К тому же, в redmine из коробки можно строить древовидную структуру задач. Тогда у вас появится хоть какой-то контроль и вы сможете планировать. Либо не заморачиваться, т.к. 1 или 2 задачи на ситуацию не повлияют, и пусть разработчики сами делят задачи и планируют.

Есть разные варианты даже в git-flow. В вашем случае, с учётом того, что вы делаете фичи, а затем выбираете, что пойдет в релиз (не очень понятно как вы формируете спринт при этом), ветка develop вам по-сути не нужна. Ветка develop предназначена для интеграции разных фич и проверки их совместной работы, в вашем случае это откладывается до финального тестирования релиза. Такой путь даёт гибкости, но может увеличить время финального тестирования, оправдан для несложных проектов и/или проектов с действительно слабым зацеплением, но даже в этом случае требуется постоянный контроль со стороны тимлида.