Как Scrum-мастер помогает Владельцу продукта. О чём умалчивает Руководство по Scrum

Данной статьёй я открываю серию статей, в которых буру раскрывать, а точнее закрашивать белые пятна Руководства по Scrum (Scrum Guide).

Первая статья закрасит несколько белых пятен в вопросе "Как Скрам-мастер помогает Владельцу продукта?"

Если вы откроете Руководство по Scrum, то увидите в нем вот такие строчки:

Давайте разберёмся с первыми двумя пунктами, написанными общими словами, более детально.

Помогает находить техники эффективного определения Product Goal и управления Product Backlog.

Как может Скрам-мастер помочь Владельцу продукта с определением цели продукта?

Скрам-мастеру необходимо пополнить свой сундучок инструментов продуктовыми шаблонами. Навыки заполнения таких шаблонов можно отработать в школах для Владельцев продуктов или в моей Школе Скрам-мастеров

Заполняя данный шаблон, Владелец продукта сможет сформулировать цель продукта (Product Goal) и довести её до других участников Scrum-команды.

Почему Скрам-мастеру важно не только знать эти Шаблоны, но и попробовать заполнить самостоятельно?

Дело в том, что в зависимости от уровня зрелости Владельца продукта, Скрам-мастер не всегда выступает в роли коуча, который задаёт вопросы, а может выступать и как ментор. Бывает, что Владельцу продукта сложно понять, что надо написать и тогда он/она спрашивает какие есть примеры, чтобы понять в какую сторону посмотреть. Также Скрам-мастеру важно понимать этот инструмент, для того, чтобы задавать правильные вопросы, например:

- есть ли problem-solution fit (PSF): решает ли найденное решение указанные проблемы (извините за тавтологию)? Как мы узнали, что решает: было ли общение с пользователями?

- есть ли product-market fit (PMF): как мы понимаем, что это наша аудитория, что мы нашли свой рынок?

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

Владелец продукта может не знать ответы на все вопросы, однако, он/она уже понимает в каком направлении необходимо подумать.

Первую часть пункта "Помогает находить техники эффективного определения Product Goal" мы с вами разобрали, давайте перейдём ко второй части "помогает находить техники эффективного управления Product Backlog"

Что же мы можем отнести к техниками эффективного управления Product Backlog? Это конечно же приоритезация, а также декомпозиция.

Для того, чтобы Product Backlog не выглядел как непонятный хаотичный список задач, Scrum-командам рекомендуется составлять Карту пользовательских историй (User Story Map).

Где этому научиться? В Школе Скрам-мастеров, мои ученики учатся составлять Карту пользовательских историй (User Story Map) через мою игру Собирашка v 3.0., а также заполняют Дорожную карту продукта. Также можно посетить мой тренинг по "Эффективной работе с Бэклогом продукта"

Картинка с дебрифа игры "Собирашка v. 3.0", где разбирается релизное планирование, элементы бэклога продукта, важность реализации технического долга и оформление в Jira
Картинка с дебрифа игры "Собирашка v. 3.0", где разбирается релизное планирование, элементы бэклога продукта, важность реализации технического долга и оформление в Jira
Дорожная карта продукта (Product Roadmap) с акцентом на то, что метрики должны помогать достижению цели. При заполнении метрики анализируются по типу: запаздывающие и опережающие
Дорожная карта продукта (Product Roadmap) с акцентом на то, что метрики должны помогать достижению цели. При заполнении метрики анализируются по типу: запаздывающие и опережающие

Через инструменты USM и Product Roadmap Владелец продукта транслирует приоритеты элементов бэклога по ценности и здесь также Скрам-мастер помогает Владельцу продукта, обладая знаниями и навыками приоритезации:

Давайте перейдём с вами к следующему пункту помощи Владельцу продукта со стороны Скрам-мастера: помогает Scrum Team осознать необходимость четких и лаконичных элементов Product Backlog;

Итак, замечательное слово "осознать", то есть "понять", что они необходимы. На такое всегда хочется ответить: "Мы понимаем, а делать то что?"

И вот как раз отвечая на вопрос "А делать то что?", мы приходим к тому, что Скрам-мастер помогает Scrum-команде с настройкой процесса, который позволяет эти элементы создать четкими и лаконичными, а это ни что иное, как Discovery-процесс. Вот так незаметно зашифровался этот процесс в Руководстве по Scrum.

Картинка с тренинга моего коллеги <a href="https://t.me/productovka" rel="nofollow noreferrer noopener" target="_blank">Димки Кустова </a>
Картинка с тренинга моего коллеги Димки Кустова 

Без эффективного процесса исследования/discovery бэклог продукта так и будет чем-то не чётким и не лаконичным и когда кто-то из участников команды задаст вопрос, что там по критериями приёмки, в ответ будет тишина и в итоге будет сделано то, что не просили или очень много времени в цикле delivery будет уделено прояснению требований.

Выстраивая эффективный цикл Исследования/Discovery, Скрам-мастер может использовать инструменты Канбан-метода, а также Lean Start-Up, поэтому Скрам-мастеру важно знать и эти инструменты/подходы

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

В следующих статьях я обращу ваше внимание на другие белые пятна Руководства по Scrum.

22
Начать дискуссию