| Descrição Principal | Quando um projeto é iniciado não há nenhum esforço abrangente, que demanda muito tempo, para escrever todas as tarefas ou requisitos previsíveis. Normalmente, tudo o que é óbvio consta do projeto, o que, quase sempre, é mais que suficiente para o primeiro Sprint. A partir daí, o Product Backlog deverá crescer e mudar na medida em que se conhece o produto e os clientes.
Durante a reunião Reunião Sprint Planning, o Product Owner prioriza os itens do Product Backlog e os descreve ao Scrum Team. O time, então, determina quais itens ele conseguirá concluir no próximo Sprint e passa estes itens do Product Backlog para o Sprint Backlog. Ao fazê-lo, o time desdobra cada item em uma ou várias tarefas de Sprint Backlog para que seja possível um compartilhamento de atividades mais efetivo. Conceitualmente, o time inicia do topo da lista priorizada de Product Backlog e desenha uma linha logo abaixo do item que o time considerar ser o último possível de se concluir durante o Sprint. Na prática, não é incomum ver um time selecionar, por exemplo, os cinco itens mais importantes e dois itens que estão abaixo na lista, mas associados aos cinco iniciais.
Itens do Product Backlog podem ser tarefas técnicas ("Refatorar a classe Login para disparar uma exceção") ou mais focados no usuário ("Permitir voltar na tela de instalação"). Uma perspectiva muito interessante é descrever os itens do Product Backlog como "User Stories do Extreme Programming".
O Product Backlog pode ser mantido em uma planilha Excel. Um exemplo de um projeto real é apresentado abaixo. Essa planilha Excel mostra cada item do Product Backlog com uma priorização genérica (Muito Alta, Alta, etc.) feita pelo Product Owner. As estimativas são realizadas pelos desenvolvedores, mas é notório que são muito imprecisas e somente são utilizadas para uma grosseira alocação de tarefas nos vários Sprints.  |
