Народ, всем привет Где в Гайде написано, что PBR должен проводиться

до 10% рабочего времени?
Я чёт не нахожу

в новом нет, только в старом

У меня стойкое убеждение, что подобный вопрос я встречал на экзамене PSM

большинство вопросов остались те же, за исключением Development team -> Developers

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

Мне каж я сдавал уже по новому :)

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

Та он уже давно не событие

Нигде, насколько мне известно. PBR не входит в число формальных событий Scrum. Однако указано, что в ходе Sprint, Products Backlog уточняется по мере необходимости.

2020 убрали это

PBR это процесс и там описано

Можете пояснить? Не событие в смысле официальных событий Скрама? PBR все равно - это же рабочие встречи в ходе спринта + активность отдельных членов команды

События Скрама - это термин.

наверно Ретро в таком ключе тоже можно назвать не событием, а процессом: к ретро команда должна готовиться (отмечать для этапа сбора данных в ходе спринта полезную информацию, фасилитатор готовит дизайн сессии Ретро и тп.), после Ретро выполняются мероприятия с Ретро и т.д. Тоже чистой воды процесс. В Японии он еще Кайдзен называется

Ну тут я не спорю, но чтобы башню сотрудникам не сносило я на своих корп. тренингах пока продолжаю его называть 5м событием Скрам (не основным 😊) чтобы просто не забывали про конкретные действия. А то в нашей культуре как скажешь про процесс, то сразу люди отдельно, а процессы отдельно

Если речь про гайд, то почему неверно? Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

С удовольствием наблюдаю, сколько апологетов Скрама тебя загнобят. Надеюсь их не меньше, чем по Канбану :)

Стикер

Груминг - тоже устаревший термин )

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

Могу опять же только гадать, почему ретро остаётся ивентом: потому что в его коре лежит митинг-рефлексия, а без него процесс будет неполный. Кстати, по такой же логике и планнинг можно назвать процессом, ведь ПМ предварительно готовиться, ставит продуктовые цели и т.п. Опасная тропа, все в скраме - процесс

Если они "загнобят", то это точно не апологеты Скрама, которые уже давно не разделяют его ценностей и тем более ценностей Agile. А если Вы будете с удовольствием наблюдать, то есть шанс тоже попасть в их число 😊

Хм, спринт - это контейнер, и вне его просто ничего нет, поэтому все что ни делается Скрам-командой - всегда внутри спринта

То была шутка. Естественно апологеты Скрама никого гнобить не будут. Как сказал мой Agile коуч в Сбербанке: «В Скраме все по любви».

Да, я всех так люблю, что всем от этого больно 😊

Спасибо, согласен. Тут кстати у меня всегда встает вопрос, что PBR проводит не только РО, но и некоторые разработчики (точнее у нас аналитики 😊), и включать ли их работу на PBR в текущий спринт на планировании. Мы не включаем. т.к. 10% несущественное капасити, а как Вы?

Смотря что за работу нужно делать. Но в целом есть 2 варианта: 1. Просто визуализировать проработку бэклога на отдельной доске, и там уже каждый делает то, что нужно для проработки. При этом в спринт бэклоге нет ничего под это, просто в какой-то момент часть велосити из спринта перейдет в пбр, и статистика нормализуется с новыми вводными. Минус такого подхода в том, что если компании очень важно видеть, куда уходят трудозатраты девелоперов, то затраты на пбр выпадают из поля зрения, а велосити на деливери падает при неизменном составе. Могут быть вопросики в таком случае. 2. Создавать spike тикеты в спринт бэклоге, таймбоксить их. Это и вопрос с "пропавшей" велосити закроет, и сам процесс проработки сделает управляемым. Отдельно есть история про АБ тесты как части пбр. Я предпочитаю их пусть через спринт бэклог как полноценный инкремент

Чтоб проверить гипотезы PO, надо построить инкремент в том виде, в каком он обсуждается на планировании спринта + провести качественный обзор. Чем меньше вариативности на входе в спринт, тем меньше вероятности получить в инкременте не то, что обсуждали и соответственно упустить возможность провести качественный обзор. PBR - это любого рода процесс, который снижает вариативность на входе в спринт. Например, product goal - повысить доходимость студентов до конца курса. Одна из проблем - они не читают письма, и соответственно нужны альтернативные каналы уведомлений студентов. Но это слишком большой непонятный скоуп. Там пришлось ресерчить веб-пуши, пробовать крутить их на какие то макеты, записывать мини-демо ролик, чтоб собрать предварительный фидбэк с руководства учебного заведения, и все это чтоб команда получила необходимую фактуру для декомпозиции и оценки, а PO мог сравнить веб-пуши с уведомлениями в телегу и определиться, что именно брать в спринт. Поэтому PBR - это процесс, где может быть все что угодно для нормализации бэклога будущих спринтов.