Priorização correta do backlog gera valor de negócio?

A resposta correta para essa pergunta deve ser sempre: SIM! Afinal, para gerar valor ao seu negócio, você tem que conseguir o melhor resultado da relação entre Custo e Benefício!

Portanto não tem sentido você criar e executar um projeto dentro da sua organização que não traga esse resultado. Um projeto pode ser para lançar um novo produto da sua empresa, ou automatizar algum processo que trará redução de custos, e por aí vai…

Mas afinal, o que é um backlog? O que é e como fazer essa priorização correta?

O que é o Product Backlog?

Segundo o Guia Scrum, a definição de Product Backlog é: “uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. É dinâmico, mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. Ele lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões”. Se você deseja fazer aquela leitura “mais nerd”, aqui está o link do Scrum Guide em português.

Quem é o responsável pelo Produt Backlog?

A pessoa responsável pela criação, classificação e divulgação do Product Backlog, e decretá-lo como concluído, é o Product Owner (PO) de um time Scrum. Caso você queira saber mais sobre quem é PO temos um artigo específico sobre esse papel que deixo o link aqui.

Como criar um Product Backlog?

Para você, PO, criar o seu Product Backlog, precisará ter uma excelente visão do produto que a sua organização espera receber no final do seu projeto, pois lembre-se que você é o responsável para garantir que tudo o que é necessário será desenvolvido no seu projeto. Para ajuda-lo futuramente, deixo abaixo umas dicas para incluir no seu P.B.:

Identificador: Criar uma coluna sequencial para identificação dos itens do Backlog;
Grupo: Você pode criar um grupo ou um tema para te ajudar a classificar as suas entregas, normalmente eu utilizo esse grupo para indicar a sequência de processo dentro do meu Negócio. Por exemplo: se o seu projeto é para “diminuir o tempo de uma venda”, pense nas etapas que esse processo tem para ser concluído que podem ser: 1 – Proposta / 2 – Pedido / 3 – Nota Fiscal / 4 – Entrega. Eu utilizaria essas etapas como Grupo, pois pode ser que seja um critério de desempate de prioridades principalmente houver uma dependência de negócio do tipo “só pode vender um produto que está na proposta”;
Descrição: Nesta coluna você deve detalhar o que precisa ser feito para entregar o seu produto final, são os seus requisitos de negócio que passarão a ser uma estória. Onde será possível detalhá-la em uma próxima etapa do desenvolvimento. Você deve procurar fazer com que uma estória seja pequena e de baixa complexidade e independente;
Priorização: Incluir uma coluna que indique a prioridade de desenvolvimento desta estória que será preenchida no momento da priorização do Product Backlog
Pontos: Essa coluna também será preenchida no momento do seu Sprint Planning. Temos aqui um artigo que fala sobre uma técnica bem bacana: Conhecendo o Planning Poker, que você poderá usar para preenchê-la.

Como ordenar um Product Backlog?

Existem várias técnicas que você pode aplicar para priorizar os itens do seu Product Backlog, a mais simples é utilizar um método que chamamos de “Bubble Sort”, onde você vai comparando 2 itens por vez e estabelecendo qual é o prioritário. Você terá que repetir essa comparação com todos os itens. Só para efeito cultural, esse é o algoritmo de classificação mais lento que existe.

Mas vamos a uma das mais utilizadas, conhecida como MoSCoW, que é um acrônimo formado pelas palavras Must, Should, Could e Wont, as vogais foram introduzidas para facilitar a pronuncia.

Must (Deve): Essa categoria você deve atribuir aos itens do seu backlog que são imprescindíveis, não tem negociação, tem que ser feito e ponto final;
Should (Precisa): Essa categoria também precisa ser feita, porém não é tão essencial, pode ser executado nas próximas entregas;
Could (Poderia): Essa categoria pode ser feita, mas se não for feita, nosso produto não deixará de existir, mas se inclui-la, fará a “alegria de todos”;
Wont (Não fazer): Veja bem, não será dessa vez que será feito.

Com os critérios acima estabelecidos, você pode agendar uma reunião com todos os interessados do seu projeto, e passar por todos os itens do seu Product Backlog e classifica-los.

Além da sua prioridade, a metodologia ágil recomenda que você desenvolva primeiro os itens que trarão maior valor agregado e que necessitem de menor esforço/tempo para ser desenvolvido.

Então, depois da sua reunião para ordenar o P.B. e a estimativade esforço, veja como ficou a versão ordenada (exemplo abaixo).