Cargo cult и user story
Кто-то умный 🧠 что-то придумал, рассказал второму, тот третьему, и так далее и уже через пару пересказов от первоначальной идеи осталась только механика, и почти полностью пропало содержание (смысл).
Сейчас уже у многих есть «бэклоги», внутри которых «пользовательские истории» (или просто «истории») и, если забить в google, как их писать, то первая страница поисковой выдачи будет про дебильный шаблон:
Я, как <РОЛЬ>, хочу <ПОТРЕБНОСТЬ>, чтобы <ЦЕЛЬ>.
У людей не так много потребностей и точно тяжело себе представить условного пользователя интернет банка, который хочет «заходить по логину и паролю в интернет банк», но это встречается сплошь и рядом.
Почему вдруг «потребности» заменились на «функциональные требования»⁉️
Полагаю, причина в том, что последние в индустрии больше 50 лет, а этим вашим историям — в лучшем случае со времён ХР (который такое себе получил распространение), и опять же пересказы не способствовали правильному внедрению подхода.
«Истории» получили своё название не из того, как мы их записываем, а из того, как используем.
Давайте использовать их правильно (3 ‘C’):
❇️ card (карточка ), на которой пользователь написал свои хотелки
❇️ conversation (обсуждение) этой хотелки, выявление потребностей, выяснение деталей
❇️ confirmation (подтверждение) наших договоренностей
Кстати,
1️⃣ В #scrum никаких историй нет, а только — «элементы бэклога».
2️⃣ Кому интересно, то есть и 5С https://www.pinterest.com/amp/pin/650840583620800007/
#userstory
Кто-то умный 🧠 что-то придумал, рассказал второму, тот третьему, и так далее и уже через пару пересказов от первоначальной идеи осталась только механика, и почти полностью пропало содержание (смысл).
Сейчас уже у многих есть «бэклоги», внутри которых «пользовательские истории» (или просто «истории») и, если забить в google, как их писать, то первая страница поисковой выдачи будет про дебильный шаблон:
Я, как <РОЛЬ>, хочу <ПОТРЕБНОСТЬ>, чтобы <ЦЕЛЬ>.
У людей не так много потребностей и точно тяжело себе представить условного пользователя интернет банка, который хочет «заходить по логину и паролю в интернет банк», но это встречается сплошь и рядом.
Почему вдруг «потребности» заменились на «функциональные требования»⁉️
Полагаю, причина в том, что последние в индустрии больше 50 лет, а этим вашим историям — в лучшем случае со времён ХР (который такое себе получил распространение), и опять же пересказы не способствовали правильному внедрению подхода.
«Истории» получили своё название не из того, как мы их записываем, а из того, как используем.
Давайте использовать их правильно (3 ‘C’):
❇️ card (карточка ), на которой пользователь написал свои хотелки
❇️ conversation (обсуждение) этой хотелки, выявление потребностей, выяснение деталей
❇️ confirmation (подтверждение) наших договоренностей
Кстати,
1️⃣ В #scrum никаких историй нет, а только — «элементы бэклога».
2️⃣ Кому интересно, то есть и 5С https://www.pinterest.com/amp/pin/650840583620800007/
#userstory
Из избранного: Одна из самых важных активностей продакта
Речь пойдет о выборе приоритетов. Задач всегда больше, чем ресурсов. Это аксиома, которая справедлива и для стартапа, и для большой корпорации. Поэтому одной из главной задач менеджера продукта является приоритизация.
Существует много методов выбора самых важных задач из важных и менее важных. Я расскажу о трёх, которыми пользуюсь чаще всего.
Скоринг. Это может быть ваша личная система оценки задач по выбранным критериям или любая из популярных, таких как RICE или ICE. Главное постараться объективно оценивать каждую задачу по каждому критерию. Самый простой способ — табличка, где в строках задачи, в столбцах критерии оценки. Каждую задачу можно оценить по критериям с использованием шкалы от 1 до 4, можно задать коэффициенты критериям (они могут как увеличивать, так и уменьшать вклад в общий рейтинг) и затем посчитать суммарную оценку. В RICE вам ещё и формулу для рассчета оценки дадут готовую. После такого разбора задачи можно просто сортировать по оценке.
Модель Кано. Это не КАно из Mortal Kombat, это КанО 🙂 Очень простой подход, который направлен на баланс в разработке с точки зрения потребностей пользователей. Делим все фичи на must have, performance и wow-effect features. Для поддержания интереса к продукту нужно делать все must have, периодически добавлять performance и иметь несколько очень крутых фич для wow эффекта. Погуглите картинку "модель Кано", она все объясняет.
User Story Mapping. Сначала кажется, что этот инструмент не про приоритеты. Доска с карточками-фичами очень хорошо помогает визуализировать продукт, которого ещё нет. Сверху идут цели пользователя, ниже фичи, которые помогают их достигать и связанные с ними элементы продукта. Но финальный шаг составления User Story Map это деление карточек на релизы. Сначала пишем цели релиза и его ожидаемое влияние на бизнес, пользователя и метрики. Затем отсекаем всё лишнее кривой линией. Всё, что осталось выше первой линии — наш MVP, между первой и второй — следующий релиз и так далее.
Есть ещё масса методов, но я советую использовать эти три в первую очередь. И, конечно, здравый смысл!
——
Репост с разрешения автора канала Владимира Меркушева
#userstory
Речь пойдет о выборе приоритетов. Задач всегда больше, чем ресурсов. Это аксиома, которая справедлива и для стартапа, и для большой корпорации. Поэтому одной из главной задач менеджера продукта является приоритизация.
Существует много методов выбора самых важных задач из важных и менее важных. Я расскажу о трёх, которыми пользуюсь чаще всего.
Скоринг. Это может быть ваша личная система оценки задач по выбранным критериям или любая из популярных, таких как RICE или ICE. Главное постараться объективно оценивать каждую задачу по каждому критерию. Самый простой способ — табличка, где в строках задачи, в столбцах критерии оценки. Каждую задачу можно оценить по критериям с использованием шкалы от 1 до 4, можно задать коэффициенты критериям (они могут как увеличивать, так и уменьшать вклад в общий рейтинг) и затем посчитать суммарную оценку. В RICE вам ещё и формулу для рассчета оценки дадут готовую. После такого разбора задачи можно просто сортировать по оценке.
Модель Кано. Это не КАно из Mortal Kombat, это КанО 🙂 Очень простой подход, который направлен на баланс в разработке с точки зрения потребностей пользователей. Делим все фичи на must have, performance и wow-effect features. Для поддержания интереса к продукту нужно делать все must have, периодически добавлять performance и иметь несколько очень крутых фич для wow эффекта. Погуглите картинку "модель Кано", она все объясняет.
User Story Mapping. Сначала кажется, что этот инструмент не про приоритеты. Доска с карточками-фичами очень хорошо помогает визуализировать продукт, которого ещё нет. Сверху идут цели пользователя, ниже фичи, которые помогают их достигать и связанные с ними элементы продукта. Но финальный шаг составления User Story Map это деление карточек на релизы. Сначала пишем цели релиза и его ожидаемое влияние на бизнес, пользователя и метрики. Затем отсекаем всё лишнее кривой линией. Всё, что осталось выше первой линии — наш MVP, между первой и второй — следующий релиз и так далее.
Есть ещё масса методов, но я советую использовать эти три в первую очередь. И, конечно, здравый смысл!
——
Репост с разрешения автора канала Владимира Меркушева
#userstory
Telegram
Продукторий Владимира Меркушева
Взгляд на мир глазами менеджера продукта. Работаю в управлении продуктами уже более 8 лет (Kolesa Group, Avito, Yandex, OLX). Пишу о собственном опыте, делюсь полезными ссылками, делаю фото-репортажи из офисов IT компаний. Живу в Лиссабоне. @mervlad
fifty-quick-user-stories-cards.pdf
8.4 MB
Есть замечательный товарищ с интересным именем Gojko Adzic
📰 Он для большинства знамент тем, что придумал подход к формированию backlog под названием
👩🔬Чем он не знаменит (и совершенно зря), так это книгой в соавторстве с Davis Evans «50 быстрых идей улучшить ваше user story» – книгу можно купить leanpub и даже со скидкой за 10 баксов).
🤡 А можно посмотреть тоже самое в формате игральных карт (и даже распечатать сие добро).
#userstory
📰 Он для большинства знамент тем, что придумал подход к формированию backlog под названием
impact mapping (о чем даже написал книгу) и тем, что ввел «Specification by expample». А еще он в отличии от множества консультантов – разработчик (настоящий, а не «у меня лапки»🦖)👩🔬Чем он не знаменит (и совершенно зря), так это книгой в соавторстве с Davis Evans «50 быстрых идей улучшить ваше user story» – книгу можно купить leanpub и даже со скидкой за 10 баксов).
🤡 А можно посмотреть тоже самое в формате игральных карт (и даже распечатать сие добро).
#userstory
Видео на бранч
Короткое видео (00:17:33) про #UserStory vs #Requirements, в котором автор приводит определение того, что такое «Требования» от IEEE:
A condition or capability needed by a user to solve a problem or achieve an objective.
Что можно перевести как
«Условие/возможность, необходимое пользователю для решения проблемы или достижения цели»
И тут возникает неловкая пауза, так как из определения не следует, что «Требование» — это адский документ со спецификацией реализации.
Советую посмотреть видео самому и занять свою позицию по поводу работы аналитиков в команде, а то как бывает:
- Мы работаем по «#scrum»!
- Поставки хотя бы раз в 2 недели по задачам взятым на планировании?
- Не, у нас сначала спринт аналитики, потом спринт разработки, а в конце спринт тестирования, после которого спринт сборки и выкатки на ПРОМ/PROD. Так что да: поставка у нас раз в 2 недели, но по тем задачам, которые мы взяли в работу 3 спринта назад.
- У вас не scrum, а «scrum, но…»🤦
Короткое видео (00:17:33) про #UserStory vs #Requirements, в котором автор приводит определение того, что такое «Требования» от IEEE:
A condition or capability needed by a user to solve a problem or achieve an objective.
Что можно перевести как
«Условие/возможность, необходимое пользователю для решения проблемы или достижения цели»
И тут возникает неловкая пауза, так как из определения не следует, что «Требование» — это адский документ со спецификацией реализации.
Советую посмотреть видео самому и занять свою позицию по поводу работы аналитиков в команде, а то как бывает:
- Мы работаем по «#scrum»!
- Поставки хотя бы раз в 2 недели по задачам взятым на планировании?
- Не, у нас сначала спринт аналитики, потом спринт разработки, а в конце спринт тестирования, после которого спринт сборки и выкатки на ПРОМ/PROD. Так что да: поставка у нас раз в 2 недели, но по тем задачам, которые мы взяли в работу 3 спринта назад.
- У вас не scrum, а «scrum, но…»🤦
YouTube
Requirement Specification vs User Stories
What are software requirements and how do they relate to user stories? Is it requirement vs user story, or user story as requirement? An important part of agile software development is its user or customer focus. Our aim as software developers is to deliver…
Про #userstory и 8 способов их написания
На просторах интернета есть несколько способов рассказывать истории и каждая из них будет так или иначе про
👨🦰 пользователя,
🤖 роль,
🧑 персону
🏛 Классика
Классический формат записи:
«Я как <Роль/Персона>, хочу <Действие/Функцию>, чтобы <Цель/Ценность>»
🩳 Сокращённая запись истории
Кроме полной записи многие используют сокращённую запись:
[Роль] <Действие в форме глагола от третьего лица>, чтобы «Цель/Ценность>»
🤏 Совсем короткая запись
Когда цель или ценность самоочевидна, то получим самый краткий, но все еще "классический" формат записи.
«<Действие в форме глагола от третьего лица>»
❓Метрический вопрос
<Вопросительное слово> <Объект> <Обстоятельство>
⌨️ Утверждение, ввод данных
<Объекты> — <Новый статус>
🔁 Изменение
«Вместо <Старый способ действий>, <Новый способ действий>»
💡 Полезное изобретение
<Полезное действие/Отрицание нежелательного эффекта> в <Контекст> за счет <Принцип работы>
🚧 История про работу
Когда <контекст>, я хочу <Мотивация>, так что <Ожидаемый результат>
На просторах интернета есть несколько способов рассказывать истории и каждая из них будет так или иначе про
👨🦰 пользователя,
🤖 роль,
🧑 персону
🏛 Классика
Классический формат записи:
«Я как <Роль/Персона>, хочу <Действие/Функцию>, чтобы <Цель/Ценность>»
🩳 Сокращённая запись истории
Кроме полной записи многие используют сокращённую запись:
[Роль] <Действие в форме глагола от третьего лица>, чтобы «Цель/Ценность>»
🤏 Совсем короткая запись
Когда цель или ценность самоочевидна, то получим самый краткий, но все еще "классический" формат записи.
«<Действие в форме глагола от третьего лица>»
❓Метрический вопрос
<Вопросительное слово> <Объект> <Обстоятельство>
⌨️ Утверждение, ввод данных
<Объекты> — <Новый статус>
🔁 Изменение
«Вместо <Старый способ действий>, <Новый способ действий>»
💡 Полезное изобретение
<Полезное действие/Отрицание нежелательного эффекта> в <Контекст> за счет <Принцип работы>
🚧 История про работу
Когда <контекст>, я хочу <Мотивация>, так что <Ожидаемый результат>
Примеры будут позжеПро #userstory и 8 способов их написания с примерами
User story вошли в жизнь очень многих продуктовых команд, у некоторых так сильно, что некоторые считают, что story есть в scrum (это слово чаще всего используют, когда отвечают на вопрос «как мы работаем?») 🤦♂️
🏛 Классика
Поэтому записью
никого не удивишь.
Но все же приведу пример,
Я как начинающий агент-изменений хочу регулярно читать статьи на канале 2%, чтобы расширять свою картину мира
🩳 Сокращённая запись истории
Кроме полной записи многие используют сокращённую:
Например,
[Читатель канала 2%] пишет комментарий к публикации, чтобы помочь автору исправить ошибки (фактические или орфографические)
🤏 Совсем короткая запись
Для особо ленивых, когда цель или ценность самоочевидна (или, возможно, прописана в epic), можно опустить последний блок — так мы получим самый краткий, но все еще "классический" формат записи.
Например,
Отключить уведомления в канале 2%
❓Метрический вопрос
То есть в требовании мы узнаем, случился ли некоторый <Факт>?
Например,
Сколько просмотров постов с картинками в сравнении постов без картинок в канале 2%?
⌨️ Утверждение, ввод данных
Например,
Отложенный пост в канале 2% изменил дату и/или время публикации
🔁 Изменение
Например,
Вместо того, чтобы писать писать все посты самому, в канале 2% будут писать несколько проверенных и резервированиях авторов
💡 Полезное изобретение
Например,
Увеличить количество подписчиков в канале 2% за счет публикации смешных мемасиков, которые будут шарить подписчики
🚧 История про работу
Например,
Когда скраммастер готовится к тренингу или к воркшопу, он может быстро найти все публикации по теме #StoryPoint
Презентацию по теме можно найти у Андрея Шапиро тут и на его сайте
User story вошли в жизнь очень многих продуктовых команд, у некоторых так сильно, что некоторые считают, что story есть в scrum (это слово чаще всего используют, когда отвечают на вопрос «как мы работаем?») 🤦♂️
🏛 Классика
Поэтому записью
Я как <Роль/Персона>, хочу <Действие/Функцию>, чтобы <Цель/Ценность>никого не удивишь.
Но все же приведу пример,
Я как начинающий агент-изменений хочу регулярно читать статьи на канале 2%, чтобы расширять свою картину мира
🩳 Сокращённая запись истории
Кроме полной записи многие используют сокращённую:
[Роль] <Действие в форме глагола от третьего лица>, чтобы <Цель/Ценность>Например,
[Читатель канала 2%] пишет комментарий к публикации, чтобы помочь автору исправить ошибки (фактические или орфографические)
🤏 Совсем короткая запись
Для особо ленивых, когда цель или ценность самоочевидна (или, возможно, прописана в epic), можно опустить последний блок — так мы получим самый краткий, но все еще "классический" формат записи.
Например,
Отключить уведомления в канале 2%
❓Метрический вопрос
<Вопросительное слово> <Объект> <Обстоятельство> То есть в требовании мы узнаем, случился ли некоторый <Факт>?
Например,
Сколько просмотров постов с картинками в сравнении постов без картинок в канале 2%?
⌨️ Утверждение, ввод данных
<Объекты> — <Новый статус>Например,
Отложенный пост в канале 2% изменил дату и/или время публикации
🔁 Изменение
Вместо <Старый способ действий>, <Новый способ действий>Например,
Вместо того, чтобы писать писать все посты самому, в канале 2% будут писать несколько проверенных и резервированиях авторов
💡 Полезное изобретение
<Полезное действие/Отрицание нежелательного эффекта> в <Контекст> за счет <Принцип работы>Например,
Увеличить количество подписчиков в канале 2% за счет публикации смешных мемасиков, которые будут шарить подписчики
🚧 История про работу
Когда <контекст>, я хочу <Мотивация>, так что <Ожидаемый результат>Например,
Когда скраммастер готовится к тренингу или к воркшопу, он может быстро найти все публикации по теме #StoryPoint
Презентацию по теме можно найти у Андрея Шапиро тут и на его сайте
Почти забыл добавить основной вид #userstory 😅🤣🤪
В комментах, плиз, накидайте мемасиков про истории
В комментах, плиз, накидайте мемасиков про истории
#ШколаAgile #ПерваяСтупень #userstory
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «User Story»🗒️
В канале был день #US: пост с примерами записи US в разных форматах, пост с голыми форматами для шаринга, и даже пост-шутка, про то, как надо рассказывать истории (кстати, можно почитать посты по хэштэгу #userstory).
User Story - это один из способов описания требований к продукту с точки зрения пользователя.
На данном воркшопе мы рассмотрим следующие вопросы:
1️⃣ Что такое User Story.
2️⃣ Как управлять требованиями.
3️⃣ Упражнение на формулировку пользовательских историй.
4️⃣ Способы декомпозиции пользовательских историй.
5️⃣ INVEST.
6️⃣ Важно добавить, что данный воркшоп дает обзор основных моментов, связанных с историями, детально все эти аспекты ребята будут проходить на второй ступени Школы.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, как у вас принято управлять требованиями и на сколько детально пишите спецификации?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Андреем Мироновым в рамках запроса о помощи community.
Всем привет!👋
Мы продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе «User Story»🗒️
В канале был день #US: пост с примерами записи US в разных форматах, пост с голыми форматами для шаринга, и даже пост-шутка, про то, как надо рассказывать истории (кстати, можно почитать посты по хэштэгу #userstory).
User Story - это один из способов описания требований к продукту с точки зрения пользователя.
На данном воркшопе мы рассмотрим следующие вопросы:
1️⃣ Что такое User Story.
2️⃣ Как управлять требованиями.
3️⃣ Упражнение на формулировку пользовательских историй.
4️⃣ Способы декомпозиции пользовательских историй.
5️⃣ INVEST.
6️⃣ Важно добавить, что данный воркшоп дает обзор основных моментов, связанных с историями, детально все эти аспекты ребята будут проходить на второй ступени Школы.
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, как у вас принято управлять требованиями и на сколько детально пишите спецификации?
🤙 Остаемся на связи.
Канал 2%
____
Материалы подготовлены Андреем Мироновым в рамках запроса о помощи community.
Google Docs
Воркшоп.User story. Описание
Воркшоп. User story Цели Понять, что такое пользовательская история. Научить писать пользовательские истории. Научить использованию принципа INVEST в качестве минимального DoR Результаты Опыт формулирования пользовательских истории. Опыт проверки задач…
Статистика канала за #октябрь
Подбиваем статистику в канале по сделанным публикациям.
Получилось: 2️⃣3️⃣ публикаций в октябре (на 5 меньше, чем в сентябре – тренд на лицо: из-за загрузки писать времени нет совсем, живу на старых запасах).
Довольно необычно читать посты, написанные в прошлом – иногда не сразу понятно, что их писал я каких-то пару месяцев назад. Кажется, что автор кто-то другой (и иногда за него немного стыдно)👻
❗️В этом месяце был опубликован последний пост про первою ступень открытого проекта обучения scrum-мастеров, agile-коучей и агентов изменений Школа Agile🎉
Все материалы в открытом доступе можно найти в этом канале по хэштегу #ШколаAgile. Все посты по Школе агрегируются в googledocs.
Пользуясь случаем напоминаю, что желающие поволонтерить могут еще присоединиться, во второй ступени еще есть неразобранные воркшопы).
Ниже будет традиционная подборка лучших публикаций («лучшесть», как и «ценность», у каждого своя) за месяц.
👅 Самые обсуждаемые (🔝 по комментариям)
♦ Длительность использования сервиса не гарантирует его качество
♦ Чтобы получить результат нужно уметь создавать условия. Немного «буддизма» в ленту
♦ Внимание как индикатор проблем или почему рецепты «как правильно» работают не везде
🎁 Самые виральные (🔝по количеству public и private шарингу)
♦ #ШколаAgile: описание воркшопа по пользовательским историям #userstory
♦ #ШколаAgile: описание воркшопа по планированию спринта #scrum
♦ Зачем на самом деле нужна фасилитация
🤪 Самые пятничные посты
♦ Порефлексировал как хожу на некоторые встречи🤨
♦ Продукт для всех - продукт для никого😇
♦ Что происходит, когда не соблюдаешь спринт и впихиваешь невпихуемое🤯
Ps
Леша Пятов начал делать модель для оценки виральности постов (За что ему огромное спасибо 🤗).
Такие дела за месяц. Посмотрим, что будет в ноябре👋
Подбиваем статистику в канале по сделанным публикациям.
Получилось: 2️⃣3️⃣ публикаций в октябре (на 5 меньше, чем в сентябре – тренд на лицо: из-за загрузки писать времени нет совсем, живу на старых запасах).
Довольно необычно читать посты, написанные в прошлом – иногда не сразу понятно, что их писал я каких-то пару месяцев назад. Кажется, что автор кто-то другой (и иногда за него немного стыдно)
❗️В этом месяце был опубликован последний пост про первою ступень открытого проекта обучения scrum-мастеров, agile-коучей и агентов изменений Школа Agile🎉
Все материалы в открытом доступе можно найти в этом канале по хэштегу #ШколаAgile. Все посты по Школе агрегируются в googledocs.
Пользуясь случаем напоминаю, что желающие поволонтерить могут еще присоединиться, во второй ступени еще есть неразобранные воркшопы).
Ниже будет традиционная подборка лучших публикаций («лучшесть», как и «ценность», у каждого своя) за месяц.
👅 Самые обсуждаемые (🔝 по комментариям)
♦ Длительность использования сервиса не гарантирует его качество
♦ Чтобы получить результат нужно уметь создавать условия. Немного «буддизма» в ленту
♦ Внимание как индикатор проблем или почему рецепты «как правильно» работают не везде
🎁 Самые виральные (🔝по количеству public и private шарингу)
♦ #ШколаAgile: описание воркшопа по пользовательским историям #userstory
♦ #ШколаAgile: описание воркшопа по планированию спринта #scrum
♦ Зачем на самом деле нужна фасилитация
🤪 Самые пятничные посты
♦ Порефлексировал как хожу на некоторые встречи
♦ Продукт для всех - продукт для никого
♦ Что происходит, когда не соблюдаешь спринт и впихиваешь невпихуемое
Ps
Леша Пятов начал делать модель для оценки виральности постов (За что ему огромное спасибо 🤗).
Такие дела за месяц. Посмотрим, что будет в ноябре
Please open Telegram to view this post
VIEW IN TELEGRAM
#ШколаAgile #ВтораяСтупень #PBR #Планирование #USM #userstory #impactmap
Всем привет!👋
Мир активно меняется, становятся неактуальными предыдущие цели, но мы остаемся островком стабильности и продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе “Product backlog refinement: User story mapping, Impact mapping”👩🎓.
Уточнение Бэклога Продукта (Product Backlog Refinement) или как ещё принято называть груминг — один из непростых аспектов в работе команды, особенно на начальных стадиях проектирования проекта. User story mapping и Impact mapping — это мощные инструменты, созданные для верхнеуровневой декомпозиции продуктов и проектов.
Проводите воркшоп – учитесь сами и помогайте вашему бизнесу понять:
- как целостно спроектировать продукты, основываясь на клиентском пути
- как сформировать первичный бэклог продукта
- как выделить самое главное и учесть влияние всех участников на ход работ
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, какие инструменты планирования вы уже использовали, а какие еще только собираетесь использовать?
🤙 Остаемся на связи.
Канал 2%
Материалы подготовлены Лобановой Еленой в рамках запроса о помощи в community.
Всем привет!👋
Мир активно меняется, становятся неактуальными предыдущие цели, но мы остаемся островком стабильности и продолжаем публиковать в открытом доступе материалы Школы Agile.
Сегодня поговорим о воркшопе “Product backlog refinement: User story mapping, Impact mapping”👩🎓.
Уточнение Бэклога Продукта (Product Backlog Refinement) или как ещё принято называть груминг — один из непростых аспектов в работе команды, особенно на начальных стадиях проектирования проекта. User story mapping и Impact mapping — это мощные инструменты, созданные для верхнеуровневой декомпозиции продуктов и проектов.
Проводите воркшоп – учитесь сами и помогайте вашему бизнесу понять:
- как целостно спроектировать продукты, основываясь на клиентском пути
- как сформировать первичный бэклог продукта
- как выделить самое главное и учесть влияние всех участников на ход работ
Детали воркшопа можно найти в документе, в котором есть:
🎯 цели этой встречи;
🎁 с какими результатами нужно с нее выйти;
📋 таблицу с таймингом.
В настоящий момент пока еще доступна miro-доска.
Если вдруг все пропадет, мы подготовили выгрузку доски в файл-backup и пошарили все в папке.
✋ Делитесь этим постом с вашими коллегами, кто так или иначе связан с агентами-изменений, СМ или АК.
🗣 А в комментах напишите, пожалуйста, какие инструменты планирования вы уже использовали, а какие еще только собираетесь использовать?
🤙 Остаемся на связи.
Канал 2%
Материалы подготовлены Лобановой Еленой в рамках запроса о помощи в community.
#Статистика
ТОП самых виральных публикаций
🙊 Что дать почитать вашему продАкту?
🙊 Что такое ценность?
🙊 Как найти цель в жизни #ikigai?
🙊 #userstory и 8 способов их написания с примерами или без
🙊 Путь агента-изменений!
ТОП самых виральных публикаций
🙊 Что дать почитать вашему продАкту?
🙊 Что такое ценность?
🙊 Как найти цель в жизни #ikigai?
🙊 #userstory и 8 способов их написания с примерами или без
🙊 Путь агента-изменений!