Ao longo do tempo requisitos levantados em algum momento do projeto acabam se tornando defasados antes mesmo de serem implementados. Algumas vezes histórias do Product Backlog podem acabar sendo esquecidas e até mesmo perdendo o sentido devido às mudanças que ocorrem no projeto. Por isso é importante cuidar do Product Backlog para mantê-lo sempre alinhado à situação atual do projeto, evitando que ele fique cheio de histórias que talvez não façam mais sentido. Além disso, é importante também que a equipe participe do Product Backlog com a criação de histórias, tornando-o mais versátil e dinâmico.

O post de hoje trata exatamente da manutenção do Product Backlog expondo algumas práticas que podem ajudar a mantê-lo mais limpo, coeso e sempre alinhado às necessidades do projeto.

 

Equipes adotam metodologias ágeis justamente pelas incertezas associadas ao projeto em questão. Muitas vezes, os objetivos do projeto ainda não são completamente conhecidos e os requisitos não estão totalmente definidos de antemão. Essa é uma das razões que levam ao uso de metodologias ágeis. As histórias vão sendo criadas no Product Backlog e ao longo do tempo vão sendo selecionadas para serem implementadas dentro de uma Sprint. Porém podem ocorrer mudanças nas prioridades e nos requisitos do projeto de forma que em algum momento o Product Backlog possua histórias que não são mais necessárias. Isso muitas vezes ocorre com histórias menos prioritárias que vão sendo deixadas pra depois e nunca entram em uma Sprint.

O problema é que ao longo do tempo poderemos ter um Product Backlog cheio de histórias que não serão implementadas e que talvez sejam até conflitantes com outras histórias que tenham surgido ao longo das Sprints e não façam mais sentido para o projeto. Assim teremos um Product Backlog que não representa as reais demandas do projeto. Portanto uma prática interessante é a de estar atento às histórias que nunca entram em um Sprint Backlog, pois isto é um forte indício de que esta história talvez não seja mais necessária para o projeto. Isto pode ser feito no Planejamento 1, onde equipe e PO decidem juntos quais histórias entrarão no próximo Sprint Backlog. Percebendo que alguma história sempre fica de fora a equipe pode mostrar isso para o PO e discutir se não seria o caso de remover ou alterar a história. Outra prática interessante é, ao ter uma nova história criada, verificar se existe alguma relação entre ela e qualquer outra história do Product Backlog. Isso ajuda a identificar histórias conflitantes ou até mesmo histórias que devem ser agregadas em uma história só.

Vale lembrar que os cuidados com o Product Backlog não devem ser voltados apenas para as histórias que já estão lá! A equipe, percebendo necessidades no projeto, também pode e deve propor histórias para serem discutidas com o PO e então decidirem se devem ou não ser aprovadas. Pois algumas necessidades nem sempre são percebidas pelo PO. Esta prática ajuda a manter o Product Backlog sempre populado e permite que a equipe use sua criatividade não só na implementação das histórias, mas também para a criação de requisitos para o projeto em questão.

Enfim, não existem regras pré-definidas para a manutenção do Product Backlog. Porém as práticas expostas neste post podem ajudar uma equipe a manter seu Product Backlog mais limpo, coeso e permanentemente alinhado às necessidades do projeto.

E você, como cuida do seu Product Backlog?