Таки вопрос в том если этот процесс написания документа слишком трудоемок что бы делать его в один спринт с разработкой. Получается аналитику нужно делать на 1 спринт впереди разработки?

Я просто ответа не услышал)

Ну, да. Или даже за 2. Там ещё и проблемы могут нарисоваться, которые на оценки повлияют, и зависимости всплывут.

В общем случае не весь спринт это анализ, только разработка или только тестирование. Много задач, которые в разных комбинациях и в том числе в одном спринте.

И сам характер работ это не сделал, перекинул через забор и дальше вы сами. Аналитик заинтересован в деплое фичи от и до. Поэтому он по ней продолжает работать и с разрабами (разъясняя в деталях и дополняя) и с тестировщиками (совещательная и проясняющая функция во время составления тест сценариев, потом объясняющая функция - баг это или не баг, стоит ли обновить требования)

Тогда получается что члены одной команды работают в разных спринтах?
А как оценивать и планировать стори если она размазывается на 2,3 спринта?
Получается оценка стори это только оценка резработки и тестирования?

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

Потому что сложно, придумать, согласовать, нарисовать экраны, провести UX тест, переделать, туда пойти, сюда.

Почему в разных? В одном. То, что ты называешь аналитикой, делает не один чел, а вся команда.

Пока конкретная сторя не проработана командой до удовлетворения всех пунктов в DoR, она в спринт не может быть взята.

В этом то самая большая проблема, как при планировании задач или спринта и тп, учитывать процессы исследования, согласования, ожидания и тд

Мы просто на это отрезаем от доступного времени какую-то часть и её не учитываем при планировании, как-будто её и нет вовсе.

Ответ ясен
У вас было такое на практике?

Конечно, это обычная практика, во всех моих командах

Сколько у вас их?

Сейчас веду 4 (в разной степени зрелости) , сколько было всего - боюсь ошибиться.

Смотри, тут все просто. Приходит продакт в команду, говорит, хочу супер-фичу. Команда трёт с ним до тех пор, пока все не поймут одинаково, что именно надо. Потом команда пытается оценить. Если получается - оценивает, если нет, говорит, что нужно поисследовать и забрасывает таску на исследование в бэклог. На ближайшем планровании продакт решает, готов ли он сейчас инвестировать в исследование. Если да, то таска берётся, исследование проводится, по его результатам команда решает, готова ли она к оценке и реализации. Если да, то бинго, если нет, то перечень доп исследований, тоже через бэклог. Лимит на исследование - 1 день макс.

Бинго - это не значит, что взяли в работу. Это значит, что её можно обсуждать на планировании в соответствии с порядком, выставленным продактом.

Если команда делает все за несколько спринтов - это влияет на то, что LeadTime - это нифига не один спринт, а значит - мы нифига не быстрые. Тогда появляется втой вопрос - нафига вам спринты? Дедлайны ставить всем?

А разве была цель сделать LT в один спринт для ВСЕХ сторей?

LT - это только чтбы увидеть. Просто есть люди истово верящие, что у них LT - это спринт, и пофиг что до спринта что-то было и после тоже, а суть спринтов - это сфокусированное достижение клиентской ценности в устойчивом ритме и длина спринта выбирается чтобы взять клиентский запрос и реализовать его полностью, чтобы быстро получить обратную связь