Quão grande deve ser o tamanho do backlog do produto?
O backlog do produto deve ser atualizado pelo PO diariamente para refletir os objetivos e necessidades do produto. Mas qual deve ser o tamanho deste? Antes de responder esta pergunta é necessário esclarecer algumas características do backlog do produto.

O que é o backlog do produto?
É um conjunto de tarefas necessárias para atingir os objetivos do produto. Tais tarefas são escritas e mantidas única e exclusivamente pelo Product Owner, o formato pode variar de cenário para cenário, porém no geral são utilizadas User Stories.
O que NÃO é o backlog do produto?
Muitas vezes o backlog é utilizado de forma incorreta, representando apenas um conjunto de ideias futuras para o produto, onde são apenas uma frase ou um “placeholder”. O backlog não deve ser preenchido com ideias, este não é o objetivo. O backlog não deve ser preenchido com tarefas que não tenham um objetivo claro definido.
O backlog não é um banco de ideias! Tomem cuidado!
Como o backlog deve ser organizado?
O PO é o único que deve definir a prioridade do backlog, sendo que os critérios variam de cenário para cenário, por exemplo, se o foco do momento é aumentar a satisfação dos clientes, provavelmente o PO prioriza os itens do backlog que possam contribuir para isso. Uma maneira de facilitar isso é identificar uma métrica e relacionar tarefas que possam melhorar tal métrica.
Quanto maior a prioridade, mais informações devem estar disponíveis para a tarefa, em outras palavras, deve estar melhor preparada para ser priorizada.
Então, qual deve ser o tamanho do backlog?
Após entender melhor o que representa o backlog, podemos discutir sobre quão grande este deve ser, há várias abordagens possíveis, mas eu prefiro sugerir a seguinte abordagem:
3 meses de idade
O backlog não contem nenhum item mais antigo do que 3 meses. Significa que, sempre que o PO aplicar um filtro no backlog e encontrar itens mais antigos do que este período, tais itens devem ser excluídos, sim, estes itens devem ser excluídos, mas por que isso? Eu pergunto, por que não? O Scrum é empírico, ou seja, quanto mais se caminha, maior é o conhecimento adquirido, desta forma, itens antigos no backlog não colaboram para isso, pois o backlog precisa refletir o aprendizado.
Quando itens antigos são mantidos no backlog, o Scrum começa a se aproximar das metodologias tradicionais, onde os requisitos são escritos totalmente antes do desenvolvimento começar. Isso é exatamente o contrário do Scrum, por isso as tarefas devem ser atualizadas conforme o aprendizado obtido, desta forma as tarefas antigas passam a não ser relevantes.
Eu pergunto, se uma tarefa não foi priorizada em 3 meses, ou seja um trimestre, 6 Sprints (quinzenal). Qual o motivo de manter esta? Muitos POs podem responder, seria um nice to have, seria interessante para um momento onde o time tenha tempo para isso. Tenho um ponto de vista forte nisso, o PO precisa maximizar o valor do produto, para isso é preciso aprender cada vez mais rápido e manter o backlog atualizado para refletir este aprendizado. Minha sugestão para os POs é: não se apaixonem pelas User Stories que escrevem, foque no aprendizado e não tenha medo de adaptar a direção quantas vezes forem necessárias.
No livro Startup Enxuta de Eric Ries, o Loop do Feedback reflete exatamente isso, “construa, meça os resultados e aprenda”. Quando nos prendemos as tarefas que escrevemos no passado, nos limitamos a isso e reduzimos as oportunidades de melhor aprendizado, assim diminuindo as chances de maximizar o valor do produto.
Quer saber mais sobre este tema? Se inscreva em meu curso Como ser um Product Owner.
https://www.udemy.com/course/como-ser-um-product-owner/?couponCode=BEAPRODUCTOWNER
