Когда стоит выполнить переоценку User Story?

В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».

Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.

Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.

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

2 хороших способа приоритизации элементов бэклога

Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.

Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.

Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.

Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.

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

- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.

Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.

- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.

- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.

Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.

Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.

Подробно об этом методе читайте в блоге.

А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)

Нужен ли вам аудит команд и чем его заменить

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

Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.

1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.

С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.

2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.

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

Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.

Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.

—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39

Итак, подарки открыты, все новогодние фильмы посмотрены, а впереди еще несколько дней каникул.

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

Команда OnAgile подготовила для вас небольшой адвент🎁 с рекомендациями, которые помогут подготовиться к первому рабочему дню и начать 2022-й максимально продуктивно.

Каждый день мы будем публиковать по одной карточке с небольшим заданием на 3-5 минут. Не забывайте пересылать друзьям и коллегам.

Начинаем!

Мысленная ретроспектива 2021 года

Отвлеченный от рабочих будней контекст долгого праздника — самое время ненадолго вернуться в 2021 год и спросить себя:

🔹 Чем из того, что я (или моя команда) сделали в ушедшем году, мы действительно можем гордиться?
🔹 Какие из проблем, с которыми мы столкнулись, можно было решить гораздо проще и быстрее?
🔹 Что из сделанного оказалось не очень полезным и можно было не тратить свои силы и время на это?

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

Новые идеи по продукту

🔹 Попробуйте посмотреть на продукт, которым занимается ваша команда, свежим взглядом: что может дать значимый толчок в его развитии и что для этого следует сделать сразу после праздников?

Например, можно протестировать несколько интересных на ваш взгляд гипотез, которые могут дать ценные данные и подтолкнуть к новым идеям.

🔹 Также рекомендуем лишний раз посмотреть продукты/сайты конкурентов: на что они делают упор, что появилось интересного в этих продуктах за последнее время, что конкуренты говорят клиентам о себе и о своем сервисе?

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

Клиенты и конверсия

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

Например:
🔹 Кого из конкретных клиентов (или представителей определённого сегмента) можно было бы кратко проинтервьюировать в первые рабочие дни, чтобы лучше понять, что им сейчас нужно, как они взаимодействуют с нашим продуктом, что у них не совсем получается?
🔹 Как выглядит конверсия на разных этапах пути клиента: какой процент людей возвращается, какой процент делает полезное действие, на каком этапе уходит больше всего клиентов и с чем это может быть связано?
🔹 Какой ещё сегмент клиентов мы могли бы привлечь, чтобы протестировать их интерес к нашему продукту? И как это обернуть в высококонверсионное ценностное предложение?

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

Встреча с командой по ближайшим целям

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

🔹 Что нам предстоит сделать в ближайшие 2-3 месяца? На чем нам следует сфокусироваться? Как мы сможем измерить результат?
🔹 Еще один важный вопрос — что можно улучшить в процессах работы команды. Что мы можем сделать по-другому по сравнению с тем, как работали в прошлом году? Вспомните, как проходили стендапы, планирование и другие командные встречи: были ли они достаточно эффективными? Как можно их улучшить?

Запланируйте встречу на первый или второй рабочий день, пока у всех еще свободны календари. Такая встреча будет полезна и с точки зрения укрепления внутрикомандных связей и поможет быстро настроиться на рабочий ритм.

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

Желаем вам чудесного, интересного и продуктивного года!

Команда OnAgile

Стартовал новый тренинговый сезон🚀 Так что если вы планируете развить компетенции в сфере Agile, выбирайте программу, которая отвечает вашим интересам, а мы позаботимся о том, чтобы трехдневный интенсив принес вам максимум практических знаний

Ближайшие тренинги

1. Фундаментальный курс по всему, что есть в Agile: Scrum, Kanban, SAFe, LeSS

Cамый широкий по охвату тем тренинг, основной курс по гибким подходам, включающий Scrum, Kanban и обзор фреймворков масштабирования. Идеальная программа для тех, кто присоединился к scrum-команде или планирует перестроить работу своей команды.

Ближайшая группа на следующей неделе, 26 – 28 января. Забронировать участие.
Следующие группы 01-03 марта, 20-22 апреля, 18-20 мая, 20-24 июня

2. Продвинутый курс для Владельцев Продуктов

Углубленный курс по созданию, выводу на рынок и развитию продуктов в быстроменяющейся среде. Включая управление ожиданиями заказчиков, работу в agile-команде, проектирование и развитие продукта на основе глубокого понимания потребностей клиентов.

Ближайшие группы 09 – 11 февраля, 25-27 мая, забронировать участие.

3. Продвинутый курс для Скрам-мастеров
Лучший тренинг по отзывам 2021 года — продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.

Ближайшие группы 23-25 февраля, 27-29 апреля, забронировать участие.

4. Курс по управлению проектами в Agile

Менеджеры проектов выбирают тренинг Agile Project Management, в программе которого мы разбираем все аспекты современного подхода к управлению проектами в гибкой и гибридной среде, от дизайна проекта и оценки рисков до взаимодействия с подрядчиками.

Ближайшие группы 29 – 31 марта, 28-30 июня забронировать участие.

5. Курс по Agile для сотрудников HR

Специальный курс для HR-специалистов и руководителей HR департаментов — Agile в HR. Ранее доступный только для корпоративных клиентов тренинг теперь проходит в открытом формате. Разберем развитие HR-сервисов, мотивационной стратегии и организационной структуры компании на основе agile-практик, процесс найма и онбординга сотрудников.

Ближайшая группа 06 - 08 июня, забронировать участие.

Как расширить команду и не провалиться в организационный хаос?

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

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

В ближайших постах мы подробно поговорим о фреймворках масштабирования SAFe, LeSS и Nexus, о модели Spotify и других гибридных решениях.

Первая часть — ошибки, с которыми сталкиваются СЕО и СТО на старте увеличения численности — уже доступна в блоге: https://onagile.ru/trends/business-agility/scaling-the-company-part-1-growth-mistakes

С какими сложностями сталкивалась ваша команда при увеличении штата?

На пути к «компании будущего»

Рост численности сотрудников и команд вынуждает компанию пересмотреть свою структуру.

SAFe — один из самых популярных фреймворков масштабирования — предлагает рассматривать организацию, как взаимодействие трех уровней:

1. Уровень портфеля
2. Уровень координации (или программы)
3. Уровень команды

Подробнее о структуре, ролях, которые появляются в SAFe, и их особенностях читайте в нашем блоге

Друзья! Ищем себе в команду двух (пока двух) мобильных разработчиков, iOS и Android, уровня senior.

Мы (OnAgile и компания наш клиент) работаем над развитием европейского финтех продукта, сейчас масштабируемся по географии и объёмам клиентов/транзакций.

И нам очень нужно крутое мобильное приложение, которое будет радовать клиентов.

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

Официальное оформление, соцпакет, работа онлайн (или офис, если вы в Москве и хотите выбраться из дома и поработать в тишине) и прочие прелести финтеха.

Если интересно, присылайте резюме и небольшой сопроводительный текст о себе вот сюда: dmitry@onagile.ru

Разработка, основанная на данных

Известный факт, что лучшие решения принимаются на основе данных.

Так, например, разработка новых фичей продукта просто потому что попросил бизнес, даст качественно отличный результат от разработки, основанной на анализе ключевых метрик продукта.

Хочу порекомендовать отличный бесплатный инструмент, который мы последние полгода используем почти в каждом новом проекте - metabase.com

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

Например, что обычно смотрим мы:
- Данные по регистрациям новых клиентов, включая источники
- Основные показатели активности за день/месяц
- Возврат клиентов (retention) по когортам
- Эффективность рекламных каналов
- Отработка бэкофисных процессов (верификация, aml, anti-fraud)

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

Зато в команду приносятся не фичи, а основанные на данных гипотезы. И если кто-то из стейкхолдеров говорит «точно нужно сделать вот это», утверждение можно легко проверить на валидность по имеющимся данным и не тратить на его реализацию время и силы.

Agile-коуч: нанимать или нет?

Крупные компании отвечают на этот вопрос однозначное «да»: обычно сначала подключаются внешние эксперты — на этом этапе мы помогаем разработать план изменений и начать внедрять гибкие подходы, — а затем в штат нанимают внутренних agile-коучей для поддержки нового процесса и его дальнейшего масштабирования.

Но это гиганты рынка с их ресурсами. А как поступить компании среднего размера или небольшому стартапу?

Для начала предлагаем разобраться, кто вообще такой эджайл-коуч, за что он отвечает и какие выгоды может принести компании: читайте об этом новый пост в блоге и, если возникнут вопросы, будем рады обсудить в комментариях.

Друзья!

События в мире не смогли обойти и Agile сообщество. Хотя в это трудно поверить.
Один из сертификационных центров, Scrum.org, приостановил работу с Россией по проведению тренингов и выдаче сертификатов.

На сегодняшний день это не затронуло нашу сертификацию от ICAgile.

Все тренинги из нашего расписания актуальны (https://onagile.ru/trainings) и будут проведены в указанные даты.

Даже если временно ограничат выдачу сертификатов, мы заранее оповестим всех участников и найдём решение.
Ведь главное - это знания, которые помогут вам в карьерном росте и повышении дохода.

Так же, мы по-прежнему проводим обучение в корпоративном формате, без изменений.

Ждём вас на ближайших тренингах!

Команда OnAgile

Кто еще нужен в SAFe?

Продолжаем серию постов о расширении компании с помощью фрейворка SAFe.

Для организации слаженной работы нескольких команд в SAFe есть специальные люди: Release Train Engineer ("Машинист"), Архитектор решения и Системный архитектор.

Узнать подробнее об этих ролях

Как стать Скрам мастером в 2022 году

Получаем много вопросов о том, как сейчас найти первую работу в роли Скрам мастера: чему учиться? пригодится ли предыдущий опыт? как пройти собеседование?

Собрали ответы на основные вопросы в пост: опытные Scrum-мастера это знают, а новичкам будет полезно.

Чек-лист запуска продукта

Поиск новых сервисов и ИТ-инфраструктуры взамен временно недоступных показал, что у многих продуктов аналогов нет или они серьезно не дотягивают до лидеров рынка. И пока пользователи адаптируются к новым условиям, разработчики и предприниматели готовятся заполнить опустевшие ниши.

Потребностей клиентов много, но даже в таких условиях не все блестящие идеи переживут встречу с реалиями рынка. Поэтому прежде чем браться за разработку, предлагаем обратиться к проверенным инструментам продакт-менеджмента, которые помогут минимизировать риски:

✅ Формирование гипотез. Какими бы логичными ни были наши представления о новом продукте/фиче, они должны быть подкреплены реальными данными: исследованиями по схеме “боль — решения”, результатами проблемного интервью, фреймворком Jobs to be done.

✅ Валидация гипотез. До начала работы над продуктом каждая гипотеза должны быть провалидирована. Важно научиться тестировать гипотезы быстро и дешево, чтобы не застревать на этом этапе и сэкономить ресурсы.
Например, можно тестировать гипотезы с помощью Riskiest Assumption Test. Хорошее описание метода есть у Андрея Торбичева, партнера венчурного фонда «Месторождение» и автора канала «Индекс дятла»: ребята валидируют предположение за 1 неделю, и в рамках спринта успевают проверить 5 гипотез.

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

✅ Ориентируемя на быстрый выпуск MVP (Minimal Viable Product, минимально жизнеспособный продукт), который позволит получить обратную связь от пользователей.

✅ Настраиваем циклы обратной связи: отзывы A/B тестирования, отзывы пользователей MVP, регулярный анализ полученной обратной связи и внесение изменений в продукт на ее основе помогут вовремя сориентироваться, если потребности или поведение пользователей изменится.

✅ Регулярно сверяемся с фин.моделью. Внешние условия могут быстро меняться, и важно отслеживать финансовые показатели.
Пример из недавнего опыта наших клиентов: волатильность рубля в определенные дни оказалась настолько сильной, что если бы они срочно не изменили подход к взиманию комиссий за операции с рублем, всего за несколько дней ушли бы в значительный минус. Но быстрая корректировка условий позволила удержать финансовые показатели.