O que é backlog? O guia do fundador não-técnico

O backlog é a lista priorizada de tudo o que ainda falta construir no seu produto. Por que ele é seu, e não do dev, e como lê-lo e priorizá-lo sem saber ler uma linha de código.

Camila abriu o Trello que a agência tinha compartilhado com ela e contou. Duzentos e quarenta cards. Cada um deles com uma etiqueta vermelha escrita “importante”. Ela rolou a tela por um minuto, fechou o notebook e percebeu duas coisas ao mesmo tempo: não fazia ideia do que ia entrar no ar no mês seguinte, e, pior, ninguém mais fazia. Durante seis meses ela tratou aquele backlog como assunto do time técnico. Aquela lista era, na verdade, o produto dela.

Um backlog é a lista priorizada de tudo o que ainda falta construir num produto: funcionalidades novas, correções, melhorias e ajustes, colocados em ordem pela sequência em que devem ser feitos. No desenvolvimento de software, ele é o registro único do trabalho futuro. Todo mundo que constrói o seu produto tira de lá o que faz a seguir. Se o backlog está confuso, o produto sai confuso. É por isso que ele não pode ser um detalhe que você delega e nunca mais olha.

O que um backlog é, na prática

Esqueça a definição de manual de Scrum por um segundo. Na prática, o backlog é o lugar onde mora tudo o que você prometeu construir e ainda não construiu. A tela de login social que você pediu na reunião de terça. O bug que o seu primeiro cliente reclamou. A integração com o meio de pagamento que trava o lançamento. A ideia que você teve no chuveiro e mandou no WhatsApp do dev às 23h. Tudo isso vira um item de backlog, ou deveria virar.

Duas coisas costumam dar errado com fundadores não-técnicos, e são opostas. A primeira: você trata o backlog como a lista de tarefas particular do desenvolvedor, não abre nunca, e vai descobrir tarde demais que o que estava sendo construído não é o que você imaginava. A segunda: você despeja toda ideia que passa pela sua cabeça lá dentro, o board incha para duzentos itens, e ninguém consegue mais dizer o que importa. Nos dois casos o resultado é o mesmo. Você perdeu o controle da coisa mais cara que a sua empresa está produzindo.

O backlog não é uma lista de tarefas. É uma fila de decisões.

Aqui está a virada de chave que separa quem usa o backlog de quem é usado por ele. Um item de backlog não é uma tarefa. É uma aposta. Cada card diz, implicitamente: “isto vale mais a pena construir agora do que tudo o que está abaixo dele”. Quando você coloca “notificações por push” acima de “exportar relatório em PDF”, você não organizou duas tarefas. Você decidiu que um cliente vai esperar mais pelo relatório para que outro receba o push antes. Isso é uma decisão de negócio, não uma decisão técnica.

É por isso que a ordem importa mais do que o conteúdo. Um backlog com os itens certos na ordem errada constrói o produto errado, só que devagar. E ordenar é exatamente o trabalho que um fundador pode fazer sem saber programar, porque o critério de ordenação é o valor para o negócio, e disso você entende melhor do que qualquer desenvolvedor.

Quem é dono do backlog?

A pergunta que mais aparece é “quem faz o backlog do produto”. A resposta curta e incômoda: você. Existe uma diferença entre quem mantém o backlog e quem é dono dele. O dev, o product manager ou a agência mantêm o board: escrevem os cards com detalhe técnico, estimam esforço, quebram um item grande em três menores, fecham o que foi entregue. Isso é o “como”. Mas o dono do backlog é quem decide a prioridade, o “o quê” e o “por quê”. Numa empresa de dez pessoas sem PM, esse dono é o fundador. Não dá para terceirizar.

No vocabulário do Scrum Guide, esse papel se chama Product Owner, e a regra é clara: uma pessoa responde pela ordem do backlog. Você não precisa adotar Scrum para respeitar o princípio. Precisa só aceitar que, se cinco pessoas podem reordenar a fila, ninguém decidiu nada. Escolha quem segura a caneta. Se você não tem um PM de confiança, a caneta é sua.

Como um backlog saudável se parece: a forma de funil

Um backlog bom não é uma lista plana de duzentos itens igualmente detalhados. Ele tem forma de funil.

No topo ficam os cinco ou dez itens que vão ser construídos em seguida. Esses são caros de preparar e valem o custo: bem escritos, com critérios de aceitação claros, prontos para alguém pegar e começar amanhã. No meio ficam os itens dos próximos um ou dois meses, esboçados mas não fechados. E lá no fundo ficam as ideias soltas, uma linha cada, algumas que nunca vão sair do papel. Isso é saudável. O fundo do backlog é o seu cemitério de ideias, e ideias baratas de anotar devem ser baratas de descartar.

O anti-padrão é o board da Camila: duzentos e quarenta cards, todos com o mesmo nível de detalhe, todos “importantes”. Um backlog assim não é um estoque de trabalho. É um monumento à indecisão. A regra prática: quanto mais alto o item, mais detalhado ele precisa estar; quanto mais baixo, mais vago pode ficar. Se você está escrevendo especificação minuciosa para algo que talvez só entre daqui a oito meses, está gastando o recurso mais escasso da empresa, que é a atenção de quem decide, no lugar errado.

Como priorizar sem saber ler código: o teste do próximo mês

A objeção que todo fundador não-técnico levanta: “como eu priorizo se não sei quanto cada coisa custa para construir?”. Você não precisa. Priorização é a divisão de duas colunas: valor para o negócio e esforço para construir. O esforço você pergunta. O valor você define.

Peça ao dev uma estimativa grosseira de esforço, em camisetas: P, M ou G. Ninguém precisa cravar horas. Você traz a outra metade, o valor, e disso você entende: quantos clientes isso destrava, quanto de receita depende daquilo, o que é promessa feita para um investidor ou para um cliente-âncora. Cruze as duas. Comece pelo que é alto valor e baixo esforço, deixe o alto esforço e baixo valor morrer no fundo do funil.

Quando a lista ainda estiver empatada, aplique o teste do próximo mês: se só uma coisa puder entrar no ar no mês que vem, qual é? Responda, coloque no topo, e repita a pergunta para o que sobrou. É uma pergunta idiota de tão simples, e é a que expõe na hora quando “tudo é prioridade”, que é a mesma frase que “nada é prioridade”. Para transformar essa fila em uma sequência que você comunica ao time e aos sócios, o roadmap de produto é a ferramenta seguinte; e para escolher entre itens do mesmo tamanho, vale um método formal de priorização de features.

Os sinais de um backlog doente

Você não precisa ser técnico para diagnosticar um backlog ruim. Os sintomas são visíveis a olho nu:

• Tudo é P1. Se toda etiqueta é vermelha, você não priorizou, só pintou. Uma fila em que tudo é urgente não é uma fila.
• Itens fossilizados. Cards de seis meses atrás que ninguém abre nem apaga. Um backlog é vivo. O que não vai ser feito deveria ser deletado, não guardado por educação.
• Bug e feature no mesmo monte. Correção do que quebrou e ideia nova são decisões de natureza diferente e competem por atenção diferente. Misturar os dois esconde o que é dívida do que é ambição.
• Você não acha onde mora uma promessa. Você garantiu a um cliente que a exportação sai em março e não consegue apontar o card. Se a promessa não está no backlog, ela não existe para quem constrói.
• O board cresce, o produto não. Duzentos itens dentro, dois no ar por mês. O backlog virou depósito, e depósito não é priorização.

Um desses sinais é ruído. Três ou mais e você não tem um backlog, tem uma lista de desejos que ninguém está gerenciando.

Backlog, roadmap e escopo: quem é quem

Três palavras que os fundadores confundem, e que fazem trabalhos diferentes. O backlog é a lista priorizada de tudo o que falta, viva e reordenável a qualquer momento. O roadmap é a leitura dessa lista no tempo, a sequência que você mostra para sócios e clientes. E o escopo é a fronteira: o que entra e, mais importante, o que fica de fora de um projeto. O backlog alimenta o roadmap; o escopo define de onde vêm os itens que entram no backlog. Quando essas três coisas viram uma só planilha bagunçada, é aí que o projeto começa a inchar sem que ninguém tenha decidido.

O backlog é onde o seu produto se torna concreto, item por item, decisão por decisão. Tratá-lo como assunto do time técnico é entregar o volante da coisa mais cara que você está construindo. Ele é seu. A boa notícia é que a parte difícil, decidir o que importa, é justamente a parte que não exige código.

Perguntas frequentes

O que significa backlog?

Backlog é uma palavra em inglês que quer dizer "acúmulo" ou "trabalho represado". No desenvolvimento de software e na gestão de produtos, virou o nome da lista priorizada de tudo o que ainda falta construir ou corrigir num produto. É um termo que se usa sem traduzir no mercado de tecnologia brasileiro.

Quem faz o backlog do produto?

Quem mantém o board no dia a dia costuma ser o desenvolvedor, o product manager ou a agência. Mas o dono da prioridade, quem decide a ordem, é uma pessoa só: o Product Owner. Em startups pequenas sem PM, esse papel é do fundador. Manter é técnico; priorizar é decisão de negócio, e não se terceiriza.

O que é backlog de produto (product backlog)?

É o tipo de backlog mais comum no software: a lista oficial e viva de tudo o que um produto precisa, das funcionalidades novas às correções. Difere do "backlog da sprint", que é o recorte pequeno do product backlog que o time se compromete a fazer em um ciclo curto de uma ou duas semanas.

O que é backlog de uma empresa ou de clientes?

Fora do software, "backlog" aparece em outros contextos: em vendas, é o volume de pedidos fechados e ainda não entregues; no financeiro, receita contratada e não reconhecida; no suporte, a fila de chamados de clientes em aberto. A lógica é a mesma em todos: trabalho já assumido que ainda não foi cumprido. Este guia trata do backlog de produto.

Como criar um backlog do zero?

Junte num único lugar tudo o que já foi prometido ou pedido: funcionalidades, bugs, ideias. Separe correções de novidades. Para cada item, defina o valor para o negócio; peça ao time uma estimativa grosseira de esforço em P, M ou G. Ordene por valor sobre esforço e aplique o teste do próximo mês para desempatar. Detalhe bem só os itens do topo. Ferramentas como Trello, Jira ou Linear servem; a disciplina de priorizar importa mais do que a ferramenta.

Backlog e roadmap são a mesma coisa?

Não. O backlog é a lista priorizada e viva do que falta. O roadmap é a sequência dessa lista no tempo, o documento que comunica a ordem e o momento aproximado das entregas para sócios e clientes. O backlog alimenta o roadmap, não o substitui.