У меня их восемь. Блин. Надо кубик завести. Хоть шесть команд да охватим. Вариант.

У меня их восемь. Блин. Надо кубик завести. Хоть шесть команд да охватим. Вариант.

https://www.google.ru/search?q=%D0%B2%D0%BE%D1%81%D1%8C%D0%BC%D0%B8%D0%B3%D1%80%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9+%D0%BA%D1%83%D0%B1%D0%B8%D0%BA&newwindow=1&source=lnms&tbm=isch&sa=X&ved=0ahUKEwihoam6o4jfAhVoqYsKHQTPANgQ_AUIDigB&biw=1536&bih=723

И люди задействован в сразу в нескольких проектах... Часто в разных ролях.

А это как?

Нет команды продукта. Вряд ли в таком случае получится что-то планировать по-скрамовски.

А кто как в таких случаях из ситуации выходит?

Но эксперимент завершился тем, что мы команды в одну объединили

А это как?

Нет команды продукта. Вряд ли в таком случае получится что-то планировать по-скрамовски.

Это будут галлюцинации

Команда продукта есть, просто люди этой команды являются участниками ещё и других продуктов. Типа курьеры развозят почту не только для проекта "А"

Ну это означает, что участники команды продукта должны работать еще и в других командах?

Ну это означает, что участники команды продукта должны работать еще и в других командах?

Ну это означает, что участники команды продукта должны работать еще и в других командах?

Беда в том, что ПО несколько и они конкурируют между собой чтобы накидать тасков. С помошью спринта удалось ограничить немного этот хаос, ограничив число задаст наицикл. Ещё помогло умерить активность горящих сотрудников, заведя на каждого по канбан доске, где ограничили количество параллельных задач исполнителям до 3.

Процесс в котором команда не может синхронно фокусироваться на Цели Спринта приведет и руководство и команду только к разочарованию. Если руководство не верит в фреймворк и не понимает механики его работы вряд ли стоит продолжать пытаться работать по фреймворку

Руководство не принимает "эти новомодные штуки для бездельников"

Я думаю что со временем определится средняя пропускная способность команды/ спринта, и и по ней можно ориентироваться. То, что после покера не влезло, попадает в следующий спринт или дробится на мелочь, часть которой попадает в этот спринт, а остальное в следующий. Я правильно понимаю концепцию?

Мы покер используем для оценки элементов на PBR. Тут речь про планирование. И команды конечно же ориентируются на свою пропускную способность. Переносить элемент в следующий Спринт нельзя, элемент важный и нужный. Дробить тоже нет смысла, он уже дробленый и влезает в спринт при любом раскладе. Дробим тоже заранее. Общий итог обычно 30-40SP по сумме на команду, очень грубо. Планирование идет начиная сверху бэклога. Элементы выбираются по порядку. Просто бывает что к концу первой части планирования, когда команды уже набрали почти "под завязку" выпадает "тяжелый" элемент на 8,13 SP (больше 13-ти в Спринт не допускается). В этом случае возникает патовая ситуация, когда вроде еще и может кому-то влезть, но команды уже не рискуют брать такой элемент. Ибо могут не успеть в Спринт. Тем более он получиться наименее приоритетным в Спринт-бэклоге. В этом случае, как вариант, и можно бросать жребий, а потом уже посмотреть что команда уже набрала в Спринт и предложить забрать это на другие команды. Какие еще варианты?

Беда в том, что ПО несколько и они конкурируют между собой чтобы накидать тасков. С помошью спринта удалось ограничить немного этот хаос, ограничив число задаст наицикл. Ещё помогло умерить активность горящих сотрудников, заведя на каждого по канбан доске, где ограничили количество параллельных задач исполнителям до 3.

А раньше говорили что сроков у скрама нет)

Беда в том, что ПО несколько и они конкурируют между собой чтобы накидать тасков. С помошью спринта удалось ограничить немного этот хаос, ограничив число задаст наицикл. Ещё помогло умерить активность горящих сотрудников, заведя на каждого по канбан доске, где ограничили количество параллельных задач исполнителям до 3.

Нужен манагер, который будет планировать сам ))

Виртуализировали входящее от ПМ.

у меня есть обратный опыт: даже в таких условиях люди лучше планируют сами, чем менеджер)

Ад. Не надо это называть Скрамом. Потом статьи на Хабре от прошедших этот ад появляются. Скрам это все таки больше про доставку ценности, чем про утилизацию.

Ну или через неделю)

про неделю - это если спринт неделя

да я помню - у вас там круто все (без сарказма)

хорошо когда со всех сторон есть понимает как этот хрупкий механизм может работать

Agile Delivery Manager вот оказывается это о чем.