У нас флоу To Do - In Progress - Code Review - Testing - Done Сущности используем Story с саб-тасками, Task и Bug

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

В разных командах по-разному. Есть и те, где в рамках спринта аналитика проводится.

Заводим саб-таск на анализ к соответствующей стори

Еще вопрос: какой максимальный размер таска в стори поинтах? у нас сейчас парочку на 20, имхо это ненормально

Вопрос: какую цель вы преследуете, раздельно оценивая разработку и аналиику?

1.Чтобы все задачи были оценены в стори поинтах по скраму. 2.Чтобы учитывать оценки, выполнения в берндаун. 3.Тест кейсы и тестирование также оцениваем.

А зачем вам это нужно? Какая конечная цель?

в команде все кросфункциональны? т.е. нет выделенных аналитиков, тестировщиков?

А как это связано со статусами в Jira? Кроссфункциональность хорошо, но не обязательно. В вашем случае будут колонки по типу ToDo, Analysis, Dev, Review, QA, Done

мы работаем в jira. Условно по задаче три таска: 1.Написать требование; 2.Разработать; 3.Протестировать; Каждую отдельно оцениваем и заводим в jira. После распечатываем таски спринта и вешаем на доску. По выполению отслеживаем берндаун.

мы работаем в jira. Условно по задаче три таска: 1.Написать требование; 2.Разработать; 3.Протестировать; Каждую отдельно оцениваем и заводим в jira. После распечатываем таски спринта и вешаем на доску. По выполению отслеживаем берндаун.

Чё вы тут устроили Сделайте просто to do, in progress, done и все

А не надо отдельно. Пусть это будет одна задача со своим life cycle.

мы работаем в jira. Условно по задаче три таска: 1.Написать требование; 2.Разработать; 3.Протестировать; Каждую отдельно оцениваем и заводим в jira. После распечатываем таски спринта и вешаем на доску. По выполению отслеживаем берндаун.

Подробнее пожалуйста, не понимаю. Как по одной задаче распечатать три карточки на доску?

Вы же сами написали, 1.Командная работа на результат. Поэтому я бы убивал silos как только можно. Таска должна представлять собой достижение результата всей командой, а не прохождении стадии

тестирование в 80% переносится на следуюший спринт. т.е. для демо мы подготовили примеры, но полностью функционал не протестирован.

у нас 5 команд. Спринт жестко 2 недели. Аналитика работает на будующее. т.е. когда спринт начинается на разработчиков уже долны быть задачи, которые могут начинать делать уже сегодня.

У нас аналитика работала со смещением в один спринт.

бинго! Это не уклыдвается в jira, и ваше понимание, что единая задача на все этапы.

мы ее только поставили 😁

в команде все кросфункциональны? т.е. нет выделенных аналитиков, тестировщиков?

6. Подзадачи лучше оценивать в часах. – Для чего? Подскажи плиз.

1. Переносить незавершенную работу между итерациями иногда приходится, но делать это частью процесса не стоит 2. Если уж совсем никак не получается делать аналитику прям вот в спринте (кстати, почему?) - сделайте из аналитиков value team, которая будет работать с PO и помогать ему. Такая организация тоже не признак скрама здорового человека, но на ранних этапах трансформации, когда команды еще не умеют в agile требования - подходит. 3. девелоперы и тестеры должны работать в одной итерации и их надо учить работать вместе. На ранних этапах трасформации, опять же, хорошо подойдет писание тест-кейсов QA в то же время, когда разработчики пишут код, и выполнение тест-кейсов тогда, когда карточка с задачей пришла в ревью. Но в целом посмотрите в сторону agile testing, TDD\ATDD и инструментов для всего этого. ДЛя jira есть отличный плагин - Zephyr, существенно упрощающий интеграцию ручного тестирования в спринт 4. Если у вас несколько команд работают над одним продуктом, задумайтесь о system team и создании delivery pipeline. Структуру для нескольких команд хорошо подсмотреть в Nexus или Scrum@Scale. 5. Внутри спринта должна быть дна оценка в сторипоинтах, от всех членов команды. Это нужно, чтобы члены команды понимали сложность работы для каждого. Если задача сугубо аналитическая, BA дает оценку в 5, а разработчики в 0, потмоу что "а нам тут делать нечего" - у вас не получится сделать scrum-команду. Разработчикам не обязательно делать аналитику самим, но очень желательно знать, как делается анаитика. 6. Подзадачи лучше оценивать в часах.

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

Это вдобавок к вышесказаному.. А одним словом - скрам мастера бы вам =)

по п.5 Аналитику разработка алгоритма по формированию отчета 3,5 часа оценили. А разработчику закодить уже описанный аналитиком алгоритм 20 часов. Я как СА, пытался доказывать, но бесполезно.

А что именно вы пытались доказывать? Вообще такое делается при помощи planning poker и обсуждения, пока в команде не будет консенсуса по сложности.

у нас есть планинг покер. 4-5 часов планирование каждого спринта занимает. я кинул 13, остальные 1-2 посчитали среднюю.

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

ха-ха. Дайте мне этот идеальный мир.

Еще общий вопрос. РО спрашивает срок (количество спринтов) по группе задач близкого функционала. Грубо 4-5 больших задач, которые нужно на планировании разбить на таски. Как в такие поступать в таких случаях? Он же противоречеч идеи скрам.

либо, если очень хочется именно в scrum, имеет смысл поискать хорошего коуча хотя бы для консультаций.

у нас он целый месяц жил "коуч" пока внедрение происходило

С какой целью он спрашивает?

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