Gestão de backlog em projeto de e-commerce: exemplo comentado

A gestão de backlog em ecommerce tem um problema que outros produtos digitais não têm na mesma intensidade: todo mundo da empresa sabe exatamente o que quer da loja. Marketing quer um banner novo para a campanha de sexta, o atendimento quer que o cliente consiga trocar o endereço depois da compra, a logística quer outra regra de frete e a diretoria quer um aplicativo. Tudo chega como urgente, e o time de tecnologia é o mesmo.

O exemplo comentado a seguir mostra como uma loja virtual fictícia organiza esse volume de pedidos num backlog só, com critério de prioridade explícito e respeito ao calendário de vendas. A loja, os números e as decisões são ilustrativos. O objetivo é que você consiga copiar a estrutura para o seu caso.

O cenário do exemplo

Imagine uma loja de utilidades domésticas que vende pelo próprio site e por marketplaces. Ela tem um time de produto com uma gerente de produto, quatro desenvolvedores, uma designer e um analista de qualidade, trabalhando em Sprints de duas semanas. A plataforma é de mercado, com customizações. O objetivo do semestre, definido pela diretoria, é aumentar a taxa de conversão do site sem aumentar o gasto com mídia.

O backlog herdado tinha mais de 300 itens, metade com títulos como "melhorar checkout" ou "ver com o marketing". Ninguém sabia quais ainda faziam sentido. Esse é o ponto de partida mais comum, e é por ele que o exemplo começa.

Passo 1: definir quem ordena e por onde as demandas entram

O Guia do Scrum define o backlog do produto como uma lista emergente e ordenada do que é necessário para melhorar o produto, e atribui ao Product Owner a responsabilidade pela gestão dessa lista. No e-commerce, a palavra que importa é "ordenada": alguém precisa ter a última palavra sobre a ordem, senão o backlog vira uma caixa de entrada.

Na loja do exemplo, a gerente de produto passa a ser a dona do backlog (uma das responsabilidades descritas em o que faz um gerente de produto), e as demandas entram por um formulário único com quatro perguntas:

1. Que problema do cliente ou do negócio isto resolve?
2. Como vamos saber que resolveu (qual número deve mudar)?
3. Há prazo obrigatório, como campanha, contrato ou exigência legal?
4. Quem pode responder às dúvidas do time sobre o pedido?

Pedidos que chegam por mensagem ou no corredor são registrados nesse formato pela própria gerente. A regra não é burocracia: sem a pergunta 2, nenhum item consegue ser comparado com outro.

Passo 2: limpar e organizar o backlog herdado

Com 300 itens, refinar um a um levaria meses. A gerente faz uma triagem em três rodadas:

• Descarte: itens sem dono, sem problema claro e sem movimento há mais de seis meses saem da lista. Se forem importantes, alguém vai pedir de novo.
• Agrupamento: os itens restantes são agrupados em temas ligados à jornada de compra: descoberta (busca, vitrine, categorias), decisão (página de produto, avaliações, frete), compra (carrinho, checkout, pagamento), pós-compra (rastreio, troca, atendimento) e operação (integrações com estoque, marketplace e sistema fiscal).
• Detalhamento só no topo: apenas os itens candidatos às próximas duas ou três Sprints ganham critérios de aceite e estimativa. O resto fica como épico ou tema.

Para o passo a passo de montar um backlog do zero, com histórias de usuário e critérios de aceite, veja como criar seu primeiro backlog de produto. Aqui o foco é o que muda quando o produto é uma loja.

Passo 3: priorizar com critério que todos entendem

A loja adota uma pontuação simples, de 1 a 5 em cada critério, que qualquer área consegue entender e contestar com argumento:

• Impacto na conversão ou na receita (peso 3)
• Impacto no custo operacional ou no atendimento (peso 2)
• Esforço estimado pelo time (peso 2, invertido: menos esforço, nota maior)
• Risco de não fazer, como multa, perda de canal ou problema legal (peso 2)

Veja como ficou o topo do backlog depois da primeira rodada (valores ilustrativos):

Dois comentários sobre a tabela. Primeiro, o item de integração com marketplace tem nota de conversão baixa, mas um prazo obrigatório que o empurra para cima; nesses casos a gerente registra a data limite no próprio item, para que a decisão fique visível. Segundo, o novo layout da página inicial, que era o pedido mais insistente, ficou no fim. A pontuação não decide sozinha, mas obriga quem pede a mostrar por que o item merece passar à frente.

Se você quer usar dados de uso para calibrar as notas de impacto, o artigo sobre como usar dados para priorizar funcionalidades mostra como sair do achismo.

Passo 4: respeitar o calendário comercial

O e-commerce tem uma particularidade que muda a gestão do backlog: datas de pico. Black Friday, Natal, Dia das Mães e as campanhas próprias da loja concentram vendas e não toleram instabilidade. A loja do exemplo trata isso de três formas:

1. Janela de preparação. Itens que precisam estar no ar para a data (cupom novo, página de campanha, ajuste de capacidade) são marcados com a data limite e sobem no backlog com antecedência de pelo menos duas Sprints.
2. Congelamento de mudanças. Nas semanas mais próximas do pico, só entram no ar correções que impedem a compra. O time aproveita para refinar o backlog do período seguinte e pagar dívida técnica que não toca o checkout.
3. Revisão depois do pico. Os números da data (conversão, abandono de carrinho, chamados no atendimento) alimentam a pontuação dos itens seguintes.

Quando o mercado muda no meio do caminho, por exemplo com um concorrente oferecendo frete grátis, a gerente reabre a pontuação dos itens afetados em vez de esperar a próxima revisão mensal.

Passo 5: refinar um item até ele ficar pronto para a Sprint

Pegue o item campeão, "mostrar prazo e valor do frete na página do produto". No refinamento, o time descobre que ele depende de uma consulta à transportadora que hoje só acontece no carrinho. O item é quebrado em três histórias:

• Como cliente, quero informar meu CEP na página do produto e ver o prazo e o valor do frete, para decidir antes de colocar no carrinho.
• Como cliente, quero que o CEP informado fique guardado durante a navegação, para não digitar de novo em cada produto.
• Como loja, quero registrar quantas consultas de frete viram compra, para medir o efeito da mudança.

Os critérios de aceite da primeira história incluem o tempo máximo de resposta, a mensagem quando a transportadora não responde e o comportamento em celular. A terceira história existe porque, sem ela, ninguém saberia se o item mais bem pontuado de fato aumentou a conversão.

Backlog de produto e backlog de projeto na mesma loja

Em algum momento, a loja vai ter um projeto com começo e fim: trocar de plataforma, abrir um canal novo, integrar um sistema de gestão empresarial. Esse trabalho tem escopo fechado, prazo e orçamento próprios, e costuma ganhar um backlog de projeto separado, que convive com o backlog contínuo da loja. A diferença entre os dois está explicada em backlog de projeto e backlog de produto, e a distinção entre o que a loja deve fazer e o trabalho para entregá-la, em escopo do produto e escopo do projeto.

Sinais de que o backlog da loja saiu do controle

• O topo muda toda semana conforme quem gritou mais alto.
• Itens entram na Sprint sem critério de aceite e voltam para o backlog no meio do caminho.
• A equipe não sabe qual número cada entrega deveria mover.
• Correções urgentes consomem a maior parte da capacidade há várias Sprints seguidas.
• Itens com prazo obrigatório são descobertos na semana do prazo.

Qualquer um desses sinais pede uma rodada de limpeza e uma conversa com as áreas sobre o critério de priorização.

Como aplicar na sua loja

Comece pequeno: defina o dono do backlog, crie o formulário de entrada com as quatro perguntas e pontue apenas os 20 primeiros itens com os critérios do exemplo. Na Sprint seguinte, revise os pesos com as áreas. Para aprofundar a priorização, a descoberta e as métricas que sustentam essas decisões, o curso de gestão de produto da Projeto Diário trabalha o ciclo completo de um produto digital, do problema do cliente à leitura dos resultados.