как я понял там проблема глубже - сам бизнес считает в порядке ситуацию когда надо дать оценку в условиях неопределенности

Кстати, еще один вопрос вытекает, у нашего coacha есть свой инструмент, который он сам писал для создания story cards и распределения тасков.
Тулза очень медленная и нет никаких интеграций. При этом к тулзу имеют доступы только тимлиды и бизнес представители.
Декомпозировать сказали в жиру(что для меня очень даже ок),вся команда сидит на автоматизацие(time tracking в жире, gitflow по feature бранчам),но потом все задачи отписывать в этом неком тулзе от coacha.
Я уже который день говорю, что это трата моего времени, так как я так же пишу код, а не только поручаю все команде.
При этом, говорят что жира не понятна бизнес представителям, и они не могут отслеживать прогресс спринта там.
Насколько это проблема тимлида?

Да, и говорят, ну у вас же есть компоненты и создать страничку должно занимать минут 20-40.

Если тимлид видит в этом проблему, то бизнес ДОЛЖЕН ее решить. НЕОБХОДИМО чтобы команде было удобно работать. Без этого нормально не работают. Это как дать мастеру тупой топор. Он все сдалает, но сколько времени и сил потратит?

Настройте жиру так, чтобы было понятно.

И на мой взгляд меняйте коуча.

Коуч должен подходить команде, выстраивать процессы в ней, а не идти на поводу у бизнеса

и там еще где-то должен быть продакт оунер между бизнесом и разработкой, и решать вот такие вопросы

Скажем так, им никогда не была удобна жира, а я трачу свое время на перенос юзер стори в конфлуенс и соединяю все в одно целом для удобств команды

Это должен делать скрам-мастер как раз (в идеале)

Либо ты не пишешь код :)

Благодарю за дельные советы, наконец смог уложить в голове правильный подход. Спасибо!

тебе спасибо за интересный кейс, прямо кладезь антипаттернов с ненужными действиями (а-ля перетаскивание руками юзер стори)

))

 1) нету спецификации и стандартов работы с бекендом 
2) нету еще макетов по которым должны делаться интерфейсы 
3) не описаны последствия модификации изменений на существующую систему

Позвольте вставить свои пять копеек.
Если у вас нет «спецификации», то есть контракта с бекендом, то Тим Лид как раз хороший человек, чтобы написать новую историю для описания Raml или OpenAPI. Следующая Стори для UI/UX - моки юзер-интерфейса.
Estimations в скраме даёт команда, а не Тим-лид. Оценка в часах всегда не работает. В скраме мы оцениваем стори в относительных единицах User Stories и считаем сколько US points было завершено каждый спринт. Цель - сделать поток предсказуемым в целом. Часы опасны потому что создают давление. Даже если возможно что-то сделать за 2 часа, возможно нужно потратить больше времени чтобы написать UI-тесты, поговорить лишний раз с продактом, сделать демо внутри команды.

Кладезь антипаттернов - надо будет взять формулировку на вооружение, а то "сраная говноконтора с тупыми и ленивыми менеджерами" сильно длиннее

Ребята, посмотрите PR, может что убрать/добавить? - https://github.com/tlbootcamp/tlroadmap/pull/166

Посмотрю сегодня

А расскажите про ваши самые страшные тимлидовые страхи и фобии - из-за чего вы фрустрируете, чувствуете себя ненужными и не хотите приходить на работу?)

Ага, пасиб

Не набирается 269 фактов? :)