У вас там якийсь anti-agile, чи шо 😂
- будь-яка задача, яка не вміщується в умовні 8 пойнтів (знову ж таки, це не естимейт часу, це естимейт складності) - має бути поділена на дрібніші тікети
- 1 2 3 5 8 13 (fibonacci) - це тільки один з варіантів, як ставити пойнти. Є варіанти з 0.5, я навіть бачив -1 0 1
- будь-який тікет має бути можливим індивідуально відтестувати і задеплоїти у прод (якщо dependencies - feature flagging etc) - ci/cd baby
- нормальний флоу - це приблизно так плюс мінус
1. Клієнт хоче фічу, продакт вирішує, чи будемо ми це робити в принципі, та збирає і організовує в нормальному вигляді client requirements
2. Це потрапляє до архітектури, яка робить solution document і можливо невеликий proof of concept якщо потрібно
2а. Паралельно десь там UI/UX працює, мокі шмокі
3. На основі цього документу, моків та власного розуміння продакт створює один чи більше епиків та наповнює їх user stories
4. Виставляються пріоритети, вирішується, які команди будуть робити які епіки
4а. Архітектура робить handoff для девів, розповідає та пояснює прийняті рішення
5. Епік потрапляє до команди, команда на рефайнмент мітингу рефайнить юзер сторіс, додає технічні описи, створює сабтаски та призначає сабтаскам пойнти, а також визначає блокери і тд
6. Після цього продакт має приблизну картину об'єму роботи і базуючись на комбінації виділених ресурсів/команд, приоритетах та історичних значеннях velocity per team, може приблизно вирахувати естімейт у часу для клієнта з запасом на ризики, непередбачувані ситуації і тд
7. На art sync мітингу обговорюються блокери між командами ("фронту потрібні оці тікети скоріше, шоб почати їх роботу", і тд)
Все шо описано вище - це стандартний підхід, нічого нового там нема, але воно scalable для тасок майже будь-якого розміру
