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

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