Как команде проработать действительно эффективный спринт?

Все эти обязанности лежат на плечах владельца продукта. Именно он должен помочь команде осознать, что должно быть сделано. В своей книге Р. Пихлер «Управление продуктом в Scrum» задачу владельца продукта описал так:

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

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

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

Да, бывает так, что цель спринта не достигнута. Р. Пихлер предлагает решение ⬇️

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

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

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

#agilecareer_авторскийпост