O Product Backlog ou Backlog do Produto, é uma lista ordenada de todos os requisitos desejados para o produto, é a única fonte destes requisitos para um determinado produto. Essa lista nunca é completa, ou seja, é um artefato vivo que vai sendo modificado enquanto o produto existir. Para quem está acostumado à metodologias tradicionais, essa última definição soa estranho.
Vou explicar melhor. Como já mencionado, o Scrum se baseia no processo empírico, ou seja, o aprendizado vem com a experiência e o tempo. Desta forma, a lista de requisitos de um produto (product backlog), no início, na concepção do produto, ainda é tem muitas incertezas e requerimentos desconhecidos. Desta forma, a lista inicial contém apenas o que é conhecido, os requisitos principais. A medida que o software vai sendo concebido, novas funcionalidades e requisitos vão surgindo, assim, essa lista vai sendo alterada.
O importante é que tudo que for identificado de novos requisitos, seja adicionado a esta lista, que podem ser funcionalidades novas, requisitos, melhorias, correções que serão feitas nas próximas versões do produto. Lembrando que a lista é única e deve conter tudo, não pode haver listas separadas por exemplo, uma para bugs e outra para itens novos.
Essa lista ganha novos itens a medida que o produto evolui, seja por pressão do mercado, seja por novas necessidades, seja pela experiência dos usuários que solicitam melhorias ou novas funcionalidades. Além dos novos itens, a prioridade destes itens também muda constantemente pelos mesmos motivos. Uma vez definida a prioridade, se o item ainda não entrou na Sprint, ele pode mudar de posição na lista a qualquer momento.
A responsabilidade pelo Backlog do Produto é do Dono do Produto (product owner) e somente ele poderá incluir, excluir, alterar e muda a prioridade dos itens da lista, já que ele é o responsável por maximizar o valor do produto. O Dono do Produto pode ser influenciado por outras pessoas, mas somente ele pode realizar as mudanças nesta lista.
Caso existam várias equipes trabalhando em um mesmo produto, mesmo assim, a lista deve permanecer única, em resumo, um produto tem apenas um backlog de produto.
Definida as necessidades, os itens precisam ser detalhados ao máximo, para que sejam compreendidos pela equipe de desenvolvimento. Porém, como a lista é grande e queremos ser ágeis, os itens com alta prioridade (itens do topo da lista) terão um detalhamento maior do que os itens de baixa prioridade (rodapé da lista). É importante que o time de desenvolvimento auxilie o Dono do Produto neste detalhamento, que pode ser feito através das “User Stories”. Esse processo de detalhamento é chamado de Grooming (groom = preparar, arrumar) e o time de desenvolvimento deve separar cerca de 10% do seu tempo na Sprint para essa atividade, que pode ser feito em qualquer momento, quando o Time Scrum julgar necessário.
Veja a pirâmide abaixo, a representação de quão detalhado deverão ser os itens:
Somente os itens que estejam detalhados, no grau suficiente para ser entendido pelo time de desenvolvimento (topo da pirâmide), é que são elegíveis para uma Sprint, se não estiverem detalhados o suficiente, não poderão entrar na Sprint e certamente a prioridade do item está errada.
Outro ponto importante é que alguns itens com prioridades menores podem ser grandes demais. Esses itens, conforme vão sendo melhor detalhados, poderão ser quebrados em itens menores. Por exemplo, um item como faturamento de pedidos, poderá ser quebrado em diversas histórias de usuário menores à medida que vai sendo detalhado. Então veja que um item de baixa prioridade, conforme vai subindo sua prioridade, ele pode ir sendo quebrado em partes menores, abrindo-se novos itens, ficando mais fácil de detalhar e compreender.
Após o item ser melhor detalhado, ele então é estimado pelo time de desenvolvimento em grau de complexidade e não em horas. Para isso podem ser utilizadas várias técnicas, mas a mais comum é o Planning Poker, do qual detalharei futuramente. Os itens detalhados e estimados, são então considerados Preparados para serem selecionados na Sprint.
É comum que os itens do topo da lista, sejam suficientes para 3 Sprints, assim não se corre o risco de itens prioritários não estarem suficientemente detalhados e quebrados. Jamais deixe um Product Owner ir para uma reunião de planejamento da Sprint, sem ter itens preparados.
Resumindo, o Backlog do Produto é uma lista ordenada de funcionalidades, requisitos, melhorias e correções, que um determinado produto necessitará ao longo da sua existência. É um artefato vivo, que pode ser alterado a qualquer momento, incluindo, alterando, excluindo e mudando sua prioridade e de responsabilidade do Dono do Produto que é o único que poderá alterar essa lista, porém a mesma deve ser visível e acessível a todos os interessados no projeto.
Para ficar mais claro, clique aqui e baixe um exemplo de Product Backlog em Excel.
Até a próxima.