Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Большие элементы в Бэклоге продукта (PBI) — причина неприятных сюрпризов и повышенной вариативности в Спринте. Чем больше задача, тем больше неизвестных. Большие PBI с трудом вмещаются в Спринт, а Владелец Продукта и стейкхолдеры могут долго не видеть результатов работы Скрам-команд.

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

На актуализации Бэклога Продукта присутствовали обе команды в полном составе (Multi-Team PBR). Мы декомпозировали, оценили и подготовили Бэклог Продукта к планированию за восемь шагов.

Продолжение статьи »


Три Спринта на фичу. Что делать?

Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Продолжение статьи »


Почему в Скраме должен быть один Бэклог Продукта

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

Продолжение статьи »


Кейс по Канбану: не берите срочную работу

На тренинге Алексея Пикулева попросили помочь с проблемой.

Проблема

В отделе разработки четыре человека, все заняты работой, WIP = 4. Вдруг от Владельца Продукта прилетает срочная задача. Как быть: взять задачу или нет?

Продолжение статьи »


Критерии Готовности (DoD) определяют организационную гибкость

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

Продолжение статьи »


Что происходит, когда Команда берёт слишком много задач в Спринт

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

Продолжение статьи »


Подборка полезных статей от 4 апреля

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

Продолжение статьи »


Как определить Продукт в Скраме

Скрам и Аджайл работают с продуктами, поэтому критически важно договориться о том, что такое Продукт. Определение Продукта напрямую влияет на состав Команды Разработки, количество команд и выбор Владельцев Продукта, поэтому я рекомендую обратить особое внимание на этот этап. С чего начать определение Продукта?

Продолжение статьи »


Почему выгодно обучать сотрудников, а не нанимать новых?

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

Я знаю лишь два способа, как можно расширять навыки и компетенции Команды. Первый — объявить Владельцу Продукта о том, что нужного навыка нет и попросить его нанять специалиста с рынка. Второй — нарастить компетенцию силами самой Команды, даже если это займёт некоторое время. Чтобы понять, какой из способов выгоднее, давайте воспользуемся помощью системных диаграмм (Causal-Loop Diagrams).

Продолжение статьи »


Девять причин тонко нарезать Пользовательские Истории

Большинство Скрам-команд используют Пользовательские Истории для создания элементов Бэклога Продукта. Я часто замечаю, что Команда берёт слишком большие истории в Спринт. Это порождает много проблем, поэтому я рекомендую Скрам-командам декомпозировать задачи так, чтобы брать в Спринт 6–10 историй. Давайте подробнее обсудим, почему это так важно.

Продолжение статьи »