Backlog campeão: Como organizar gerando valor

Seu backlog está realmente sadio? Você enxerga valor real no que está listado ou já sente que o seus incrementos estão perdidos?

Introdução

Não se enganem, meus estimados POs/PMs, ter um backlog cheio de itens não significa necessariamente que seu time tem trabalho pra caramba (e nem que seu emprego está garantido).

Muitas vezes, uma ideia matadora pode surgir e encantar à todos, mas acabar perdendo prioridade em frente a outras demandas que já estavam com o seu lugar já negociado, stakeholders esperançosos, estimativas feitas, etc. E em diversos momentos, esta ideia matadora pode sim acabar perdendo sua conexão com os objetivos estratégicos do negócio. O famoso “ontem serviu, mas hoje não serve mais!”.

Backlog não deve ser tratado como um cata-tudo. Deve estar organizado, priorizado, alinhado com o valor que desejam entregar para os usuários e o negócio. Se estiver revisado então? É mágico! Melodia!

Vamos explorar algumas práticas que podem ajudar a sanitizar seu backlog de modo à gerenciar valor e não apenas tasks.

Do início: O que é um backlog de produto?

O backlog de produto (ou PB como já vi muita gente chamando) é basicamente uma lista onde todos os desejos relacionados ao produto que você gere estão anotados. O foco aqui será sempre melhorar o produto, seja sob perspectiva de novas features, correções, melhorias técnicas, segurança, entre vários outros.

A grande mágica do backlog de produto é ser uma lista viva, onde itens podem entrar, sair, sofrer repriorização, desde que estejam alinhados com a estratégia do seu produto. O dinamismo aqui é essencial para assegurar que os desejos dos usuários e da empresa sejam realizados de acordo com o roadmap.

Agora vem a bronca: backlog de produto não deve ser tratado simplesmente como uma nota promissória que você assina e deixa lá, à perder de vista. Não deve ser tratado como um depósito de ideias, pois fatalmente você sofrerá com a sanitização no futuro, perder time to market sobre várias features que podem literalmente mudar o jogo à favor do seu produto.

Por que refinar o backlog continuamente?

“Porque sim, Zequinha!”. Mentira, vamos detalhar: um backlog de produto é um compromisso que você firma com seus usuários e com a empresa relacionado à evolução do seu produto. Novamente, algo que fez sentido lá atrás talvez não seja mais tão prioritário hoje, logo, é necessário sim que um refinamento contínuo/recorrente seja adotado por todos do time.

E quando falo todos, é todos mesmo: PO, PM, Designers, Engenheiros, QAs, etc. Um bom refinamento garante que todos os itens listados estão sadios de verdade, compreensíveis, atualizados e maduros o suficiente para que decisões sejam tomadas sobre eles. E para isso, alguns pontos podem ajudar, como:

• Organizar itens em épicos e histórias: isso facilita o entendimento da entrega geral, o valor à ser conquistado e traz uma visão real sobre entregas incrementais;
• Estimar esforços e discutir valor: com itens bem escritos, o time deve ser capaz de entender o que precisa ser feito, quais indicadores a entrega irá movimentar, qual será o esforço necessário para a entrega (mesmo que em alto nível);
• Criar critérios de aceite: sob perspectiva do usuário, isto ajuda aos envolvidos a entender como será feito o processo de validação e mais uma vez entender o valor à ser entregue;
• Revisar prioridades regularmente: como já falei 2 ou 3 vezes, o que serviu ontem talvez não sirva hoje. Isto auxilia ao time à entender em qual direção o produto está caminhando e quais objetivos serão conquistados de acordo com o roadmap.

Como priorizar focando em valor?

Vamo lá, moçada: se tudo é prioridade, nada é prioridade. Nem se você tivesse um time de engenheiros da NASA seria possível entregar um backlog inteiro.

Lembre-se de que o backlog do produto deve ser vivo e estar aderente ao momento do produto e ao roadmap, logo, para garantir que o devido trabalho seja feito no devido momento, existem alguns frameworks que podem apoiar neste momento de decisão. Eu mesmo gosto desses dois aqui:

• Matriz RICE: framework bastante interessante onde você pode chegar à uma decisão com base em um cálculo feito de acordo com valores informados nos quatro elementos que a compõem, sendo:
• Alcance (Reach): quantidade de pessoas que esta iniciativa estima alcançar dentro de um espaço de tempo;
• Impacto (Impact): o quanto essa entrega será impactante para a experiência do usuário com o seu produto;
• Confiança (Confidence): fator necessário para evidenciar, com base no volume de dados presentes no momento, o quanto a empresa está confiante com a entrega planejada;
• Esforço (Effort): mão de obra necessária para condução do desenvolvimento da iniciativa, considerando pessoas envolvidas, custos técnicos, tempo do projeto, etc.
• Método MoSCoW: outro método interessante e muito bem aplicável para decisões sobre ciclos curtos de trabalho, como sprints, porém, adaptável a contextos de priorização maiores. É mais objetivo se comparado ao RICE, mas não menos importante, classificando itens da seguinte forma:
• Must-have (tenho que fazer): item prioritário, indispensável sob perspectiva do produto e do seu roadmap;
• Should-have (deveria fazer): itens de grande importância para o produto, mas não fundamentais ao ponto de concorrer com as Must-have;
• Could-have (poderia fazer): itens presentes no backlog que são interessantes, que podem fazer parte das prioridades no futuro, mas que não precisam ser priorizados neste momento;
• Won’t-have (não vou fazer): itens que não entrarão na esteira de prioridade. Não quer dizer que jamais serão feitos, mas sim, que não serão discutidos neste momento.

Vou deixar dois artigos muito bons que detalham os caminhos acima, recomendo a leitura:

• Matriz RICE: https://pm3.com.br/blog/matriz-rice-priorizacao-de-backlog-como-aplicar/#:~:text=Para%20isso%2C%20crie%20um%20ranking%20de%20prioridade%2C,em%20rela%C3%A7%C3%A3o%20ao%20que%20precisa%20ser%20feito.
• Método MoSCoW: https://pm3.com.br/blog/metodo-moscow-framework-para-priorizar-tarefas/#:~:text=Nesta%20categoria%2C%20voc%C3%AA%20deve%20incluir%20o%20que,ajudar%20na%20defini%C3%A7%C3%A3o%20das%20tarefas%20Should%2DHave%20s%C3%A3o:

Seu backlog está ligado aos objetivos estratégicos?

Um backlog de produto sadio de verdade apresenta iniciativas que movimentam indicadores. Isso precisa ser um fato constante e inquestionável! Uma priorização sadia de verdade deve ter como base quais métricas de sucesso do produto serão minimamente movimentadas ao decorrer da entrega.

O objetivo aqui é manter o foco no que vai movimentar indicadores reais, não apenas focar em entrega de features, faz sentido? E para isso, um bom caminho é apontar estes indicadores. Por exemplo:

• Mapear OKRs: Apontar em cada item do backlog quais OKRs poderão ser movimentados com a entrega, de forma palpável (ex: Aumentar a taxa de retenção em 10%);
• Indicadores técnicos: Para itens mais focados em engenharia, mapear quais serão as melhorias/impacto das correções esperadas (redução do tempo de carregamento em X%, redução da quantidade de erros em X%, etc).

O negócio aqui é ter sempre em mente o quanto o item do backlog pode contribuir com um objetivo mensurável. Se não souber essa resposta, tire-o da lista.

Fique atento a estes erros

Sim, eu sei que dentro do contexto de um artigo tudo é válido, as regras/opiniões parecem extremamente aplicáveis, não há qualquer desconforto entre os envolvidos e o trabalho flui perfeitamente. Porém, sabemos que no mundo real as coisas são um pouco diferentes.

Existem alguns pontos onde é natural cometer erros, ou até mesmo criar certas armadilhas das quais não conseguimos nos livrar sem um pouco de dor. Quero trazer algumas para reflexão e convido para discutirmos outras:

• Ter um backlog infinito: Falei sobre isso no começo do artigo. Um backlog imenso não é garantia de trabalho pra ninguém, mas sim uma prova clara de que seu trabalho como PO poderia ser feito com mais afinco em relação ao zelo com o produto. Revisão, sanitização e priorização devem ser feitas com frequência;
• Backlog sendo lista de desejos: Jogar um item no backlog “apenas” porquê alguém pediu não é uma abordagem interessante se você planeja tê-lo sadio. Se um item vai ganhar espaço no backlog, procure entender os motivos para que ele esteja lá, quais serão os ganhos que o produto/usuário/empresa terão quando o trabalho for concluído;
• Priorização por pressão: Este é o mais difícil (e o que mais acontece), algo subir na fila pois algum stakeholder “deu uma carteirada”. Neste momento, é interessante que seu backlog esteja priorizado e com os indicadores desejados devidamente evidenciados. A partir do momento em que a pressão surgir, ao menos você terá argumentos para justificar.

Conclusão

Um backlog de produto sadio é o reflexo do alinhamento com o roadmap, com a visão do produto e traz o tático necessário para que os resultados esperados sejam alcançados. Mantê-lo sadio, revisando e priorizando com frequência, é um grande (e necessário) passo.

Um produto é uma evolução contínua. Ele resolve problemas, traz soluções para os usuários e uma boa estratégia refletida no backlog clarifica os passos para este trabalho.

E você? Como tem gerenciado seu backlog? Compartilha suas experiências nos comentários!

Artigo revisado com auxílio de IA.