Как команде проработать действительно эффективный спринт?
Все эти обязанности лежат на плечах владельца продукта. Именно он должен помочь команде осознать, что должно быть сделано. В своей книге Р. Пихлер «Управление продуктом в Scrum» задачу владельца продукта описал так:
Вы не должны указывать команде, сколько работы нужно выполнить за спринт, или определять состав задачи от имени команды, не посоветовавшись с ней. Это прерогатива команды. И она должна брать на себя только такие обязательства, которые действительно может выполнить. Ограничение объема работы на спринт определяется скоростью работы команды и ее размерами, что в итоге создает оптимальный темп разработки.
Бесполезно пытаться добиваться слишком амбициозной цели в течение одного спринта, только чтобы полностью истощить свои силы к следующему.
Помните, что решение команды — это не гарантия. Новая команда может лишь через два-три спринта понять, как принимать решения, которые она сможет воплотить. Кроме того, в разработке ПО слишком много неизвестных слагаемых: неопределенность и риск идут рука об руку с инновациями.
Да, бывает так, что цель спринта не достигнута. Р. Пихлер предлагает решение ⬇️
Если это все-таки произошло, используйте ретроспективный анализ спринта, чтобы определить основную причину и выработать меры по исправлению ситуации. Кстати, какие методы можно использовать для разработки спринта - почитайте здесь.
Напомню, что все посты по книге можно почитать, нажав хэштег #авторскийпост. Ранее разобрали тему, как спланировать релиз в Scrum.
В этом посте были ссылки, но мы их удалили по правилам Сетки
