Backlog ou Product Backlog

Product Backlog é a relação de requisitos do produto a ser desenvolvido. Neste momento eu estou tomando como premissa que já foi realizado os trabalhos de criação do Backlog.

Um backlog deve ser organizado com os desejos do cliente de maior prioridade na parte de cima e os desejos do cliente de menor prioridade a baixo.

O backlog deve ter cada desejo estimado conforme o seu esforço, existem técnicas de Pontos de História, Dias Ideais, ou qualquer técnica de estimativa que a equipe ou empresa tenha desejo de utilizar.

 

Figura 1: Backlog organizado do mais importante a cima e menor importante a baixo, bem como o tamanho de esforço para fazer cada item do backlog

Uma técnica de medir a qualidade do backlog é a DEEP, que determina que um backlog possua um detalhamento apropriado dos desejos pelo Product Owner, que este detalhamento permita uma estimativa pela equipe, que exista a consciência de todos que o backlog não é estático e com isso pode ser mudado no decorrer do projeto e que ela seja priorizado para entregar valor de negocio ao nosso cliente.

Figura 2: Backlog DEEP

Figura 3: Exemplo de Backlog

O backlog não tem necessidade de ter todos os seus desejos especificados para o inicio do desenvolvimento. Um trabalho de especificar todos os desejos para depois iniciar o desenvolvimento de software vai promover um tempo muito grande, o que pode gerar desperdício pelas mudanças de desejo ou mudanças de interpretação dos desejos.

Figura 4: Backlog e Sprints

Devemos ter um detalhamento dos desejos apenas referente a sprint que vai ser desenvolvida ou algumas sprints a mais. Conforme o desenvolvimento vai sendo realizado, mais detalhamento dos desejos são realizados em paralelo, mantendo a distancia de tempo entre o detalhamento do desejo do cliente e a entrada para a equipe de desenvolvimento sempre curta.

Figura 5: Desenvolvimento do Time e Detalhamento dos Desejos em Paralelo

 

 

Figura 6: Não detalhe todos os desejos do projeto, apenas os que vão ser desenvolvidos

Nem sempre todas as pessoas conseguem ter uma visão do backlog organizado em uma planilha. Para isso podemos utilizar o conceito de FBS (Feature Breakdown Structure), onde podemos mostrar graficamente os desejos nos seus tamanhos e decomposições.

Figura 7: FBS

Conclusão

Ter um backlog vivo onde desejos podem entrar ou sair a qualquer momento, mesmo nos últimos momentos do projeto, não é fácil de ser aceito para quem esta iniciando em metodologias ágeis. Também não é fácil quebrar o paradigma de especificar, isso é, entender todos os desejos do cliente, deixando o detalhamento próximo da etapa de desenvolvimento de software.

Esses paradigmas são difíceis de ser quebrados, mas eles são possíveis pela mudança cultural que é a entrada do Product Owner no projeto. Devemos lembrar que ele é o responsável pela definição de desejos que permita o projeto ser bem sucedido ou não com relação ao seu retorno de investimento (ROI).

Cabe a responsabilidade dele, Product Owner, junto com a equipe ter a visão de grandeza do que é possível ser feito ou não de desejos conforme o tempo que o projeto possui.

O Product Owner é o único que pode autorizar o desenvolvimento de um desejo e ter a sua presença no projeto de maneira comprometida é um dos segredos de sucesso das técnicas ágeis.

Abraços,

Abu

Este post faz parte do material "Pensamentos Ágeis: Uma Coletânea de ideias de como penso sobre Ágil"