Validação das definições dos APO

Olá, Alexandre!

O que acontece no Less Huge é que, com a integração de muitos times, cuidar do Product Backlog fica cada vez mais difícil, tendo em vista seus níveis de detalhamento. Nesse caso, o product backlog é dividido em áreas e há um PO responsável por cada área. Assim sendo, cada Area Product Owner (APO), irá cuidar para que o Area Product Backlog (APBL) esteja refinado e detalhado. Apesar de termos as APBL, não deixaremos de ter o Product Backlog único, neste caso, o Product Owner é o responsável por gerir este backlog.

Para ilustrar com o exemplo da aula, podemos supor que existe um product backlog único em que existem dois requisitos: melhorar a perfomance e personalizar a interface do usuário. No contexto em que é necessário fazer uma priorização do product backlog único com estes dois requisitos, o PO deve fazer uma análise do negócio e decidir qual deles merece maior prioridade. Agora, sendo os requisitos separados em grandes áreas, o APO pode quebrar este requisito em histórias de usuários menores e priorizá-las de acordo com o que faz sentido para o negócio do momento. Perceba que a função de priorização, ação chave para o product owner, é executada nos dois contextos: o geral (PBL) e o particular (APBL), contudo, o Product Owner sempre terá um poder de decisão maior, tendo em vista que ele controla o product backlog único.

Perceba que, quando as coisas se organizam dessa maneira, não é necessário que o PO "referende" os requisitos do APBL, uma vez que, com a priorização natural do backlog único, entende-se qual a prioridade do momento e a partir disso, cada APO trabalha com autonomia para definir quais as APBL's estarão de acordo com a priorização feita pelo PO e tudo ocorre de maneira orgânica.

Espero que você tenha entendido, qualquer dúvida ou comentário, sigo à disposição.

Abraços e bons estudos!

No caso, o PO deve orquestrar o todo e ter uma função mais orientativa em relação aos APOs.