Сколько бэклогов нужно распределенному Agile проекту?

Это на самом деле вопрос к вам, ниже попробую описать свое текущее понимание происходящего.

Классический подход подразумевает всего два (три) бэклога - продукта, итерации и бэклог проблем (impediments backlog - немного частный случай, так как содержит проблемы, а не истории пользователей).

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

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

А что если у нас продуктовая разработка? И мы настолько гибки и зрелы, что даем пользователям добавлять сообщения об ошибках и предложения новых фич прямо в нашу систему управления разработкой продукта?
Если эти истории пользователей будут попадать в бэклог продукта, то владелей продукта будет просто не в состоянии управлять этим бэклогом.
Получается нужен еще один список историй, user backlog (не нашел такого термина в гугле) или wishlist - в который изначально попадают новые истории пользователей. Владелец продукта просматривает эти истории и, например, утверждает их, т.е. они попадают в бэклог продукта и будут отправлены в разработку.

Итого получилось 4 + 1:
User backlog - Product backlog - Release backlog - Iteration backlog (+ Impediments backlog)

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