Product Backlog / Backlog de Produto

O Backlog de Produto (Product Backlog) é um artefato utilizado em projetos Scrum que serve para listar, descrever, priorizar, organizar e medir o desenvolvimento de um produto.

A base de sua estrutura são as estórias de usuário (user stories), que nada mais são que requisitos na visão do usuário. Ex:

1. Como cliente, desejo comprar roupas de malhação
2. Quero um ambiente agradável, espaçoso, onde possa provar as roupas antes de adquiri-las
3. Desejo pagar com dinheiro, cartão e cheque
4. Desejo Poder receber os produtos que comprar na minha casa

Os estórias são escritas na visão do usuário para que, ao final do desenvolvimento, se tenha algo útil ao usuário e não apenas uma funcionalidade com uso técnico. Por exemplo: uma “API de conexão com um sistema de contas-correntes” não tem valor direto para o negócio, ao passo que “buscar clientes com contas negativas” pode ter algum.

Prioridade de negócio

Imagine que deseja montar uma loja de roupas de artes marciais, qual o primeiro passo?

Normalmente as pessoas respondem: Alugar um local. No entanto, o primeiro objetivo da loja é vender e para fazer isso não é preciso um local, mas as roupas.

Na primeira sprint, o objetivo deveria ser comprar roupas, colocar no porta-malas do carro e parar em frente a alguma academia para começar, imediatamente, a venda. Isso é valor!

Na segunda, já com algum dinheiro em caixa, poder-se-ia procurar fornecedores com maior qualidade por um menor preço. E na terceira, começar a procurar um local bacana para fazer a loja, já conhecendo o mercado e suas peculiaridades.

Portanto, o valor de negócio é diretamente relacionado ao objetivo final e, para ter o maior retorno no menor tempo possível, o projeto deve ser estruturado para testar o conceito primeiro, antes de fazer maiores investimentos. É o que o mercado chama de MVP (minimum viable product).

Se o dono do produto (product owner) descobrir que seu objetivo é inviável, poderá parar o projeto sem tantos prejuízos. Num projeto tradicional, as primeiras semanas seriam de planejamento, enquanto num projeto ágil, seriam de venda. Isso tem mais a ver com a filosofia que com a metodologia utilizada.

Organização em Sprints

Uma vez que tenha listado as estórias de usuário, é preciso medir os pontos por estória de usuário (story points) para encontrar o tamanho do projeto e organizá-lo em sprints.

No começo do projeto, não se sabe ao certo quantos story points o time será capaz de fazer por sprint. Deve-se, portanto, passar uma meta e verificar o quanto conseguem fazer ao longo de algumas sprints e, só então, se poderá calcular a velocidade do time. Apenas com a velocidade real do time, o product owner passará a ter algum nível de previsibilidade.

No Scrum, ao invés de fazer um cronograma, usa-se o conceito de Time Box, em que o tempo é fixo e o escopo é variável. Com esse conceito, pode-se economizar bastante tempo de planejamento, mas perde-se a sensação tradicional de controle do tempo. Em outras palavras, o time vai fazer o melhor possível no tempo disponível.

Medindo a evolução do Product Backlog

Para acompanhar o projeto é preciso um quadro que mostre os pontos previstos x realizados em cada sprint e a velocidade do time. Com esses dados é possível medir quando o projeto terminará (ETC – Estimate to complete), o que embasará o PO sobre a adição, redução ou modificação de estórias ao longo do projeto.

Explicação dos campos:

• A linha cinza mostra quantos pontos estão previstos para cada sprint
• A linha rosa mostra quantos foram realizados
• Os SPs (story points) acumulados serve como base para o cálculo das sprints restantes
• As horas nesse exemplo totalizam 5 pessoas trabalhando 8 horas/dia em sprints de 10 dias
• A produtividade serve para avaliar a distribuição da carga de trabalho
• As Sprints Restantes mostram quanto falta para o projeto acabar (em sprints)

Product Burndown

Outra ferramenta bastante utilizada é o product burndown, que mostra o trabalho restante em story points e deve mostrar a relação entre o previsto e o realizado.

Com esse gráfico, pode-se acompanhar avaliar riscos do projeto não cumprir a data e tomar ações preventivas (e corretivas) para mantê-lo nos eixos.

Baixe aqui a planilha utilizada no exemplo.

—

Eli Rodrigues