Ваша разработка замедляется и это…

Нормально!

С каждым годом оценка задач/трудоемкость должны расти, селя-ви.

Почему так?

1.
закон Лемана, о котором я уже писал: энтропия всегда растет!
2.
Товарищ Кент Бек (чел, который придумал экстремальное программирование и в свое время участвовал в формулировке Agile Manifesto) расписал эту же теорию, но на современный лад.
Опциональность (это из экономической теории) - количество вариантов действий/шагов, которые у вас есть для следующего шага. Как пример, шахматы. У вас на старте 20 возможных ходов. После первого хода соперника, количество ваших опций может уменьшиться (если вы ходите вторым).
Фичи - количество фичей постоянно растет (ну это нормально, если ваш бизнес развивается). И вот получается, что каждая следующая фича делает ваш продукт лучше, но замедляет с каждым новым релизом. То есть уменьшает вашу опциональность (для простоты, условно, вы выбираете некий стек и теперь завязаны на него и каждая следующая фича только усиливает эту зависимость. ORACLE в свое время подсадил на себя 80% корпораций).
Возможно вы не чувствуете это сегодня, но точно ощутите на себе завтра

Что делать?

Кент предлагает использовать Tidy First- подход.

1.
Tidying first - означает, привести код в более чистое, структурированное состояние перед новой функциональностью,
2.
Ответить на вопросы:
Что мешает следующей фиче сейчас?
Что можно упорядочить, чтобы её сделать легче?
3.
Такая работа может временно снизить скорость видимого прогресса, но в долгой перспективе убыстряет весь процесс, потому что увеличивает опциональность.

То есть, отщипнуть немного сегодня, чтобы сохранить темп. Звучит как хорошая инвестиция!

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

А как у вас дела с управлением техдолгом?
🦄 - четко выстроенный процесс, каждый спринт инвестируем ресурсы
🔥 - нууу скорее вот прямо по жесткой необходимости раз в 3-12 месяцев
💊 - памагитеее! Живем с долгом еще от 2018 года, чисто как не тех долг, а ипотека