O Product Backlog é, no Scrum, o repositório dos requisitos de um projeto, ou seja, o que precisa ser feito para o desenvolvimento do produto. Esses requisitos são, de uma forma geral, representados como histórias, ou melhor, histórias de usuários. Histórias de usuários assumem normalmente uma forma "um usuário quer que o produto tenha uma determinada funcionalidade ou capacidade, com um determinado propósito". Logicamente, outros detalhes e documentação podem e devem ser fornecidos.

No entanto, nem todo item do Product Backlog necessariamente representa uma história. O Product Owner pode inserir no product backlog itens que representam partes do produto, mas que ele ainda não detalhou o que deve ser implementado. Esses itens são chamados de épicos.

O product backlog é composto de épicos e histórias; os épicos estão num nível mais baixo de prioridade, e as histórias estão num nível mais alto de prioridade. Na realidade, não é a diferença que define a prioridade, mas a prioridade que permite a diferença. Itens de maior prioridade contêm descrições mais detalhadas e estão preparados para compor uma sprint. Os épicos, de menor prioridade, definem as futuras releases.

Quanto menor a prioridade de um item, menor a preocupação com a descrição do mesmo, mas quanto maior a prioridade de um item, maior deve ser a preocupação em detalhá-lo e descrevê-lo no Product Backlog.

O nível de detalhamento das descrições das histórias interfere diretamente nas estimativas de esforço informadas pela equipe. Isso não quer dizer que quanto mais bem descrita e detalhada estiver uma história menor será a estimativa de esforço. Significa que é menos provável a equipe errar na estimativa de esforço dada para uma história, ou seja, quanto mais bem detalhada uma história, melhor será a sua estimativa.

A equipe deve avaliar se o detalhamento da história a ser pontuada respeita a definição de história preparada.

Estimativas mais precisas implicam em maior segurança da equipe na implementação da história, pois a equipe conseguiu alcançar o entendimento da necessidade do Product Owner. 

Maior segurança implica em maior produtividade e eficiência, e maior eficiência implica na definição da velocidade da equipe com mais precisão.

O benefício da equipe ter uma velocidade média constante e precisa é a possibilidade de planejar melhor as sprints e também as releases, que dão a visão de médio e longo prazo da preparação do produto.

É importante o compromentimento do Product Owner com o projeto de forma a manter o Product Backlog atualizado e com as histórias mais prioritárias descritas com maior nível de detalhe, para que a equipe trabalhe melhor na pontuação de cada item do product backlog. Se necessário, o Product Owner pode e deve possuir uma equipe sua, de apoio, para o detalhamento e a preparação da documentação necessária para a implementação da história. Além é claro, de contar com a ajuda do Scrum Master para tratar o Product Backlog, como já previsto no Scrum. Mais isso fica para uma próxima conversa.

Suas estimativas são precisas? Você consegue definir épicos e prever releases? Traga para cá a sua experiência também.