Backlog: o que é e porque utilizar no seu projeto

Todo projeto começa com mais ideias do que tempo. O desafio comum é conseguir definir o que fazer primeiro, por quê, e como garantir que todo o time entenda isso da mesma forma.

Na Caiena, aplicamos backlog em projetos de desenvolvimento de software com clientes do setor público, privado e terceiro setor há mais de duas décadas. O que aprendemos nesse tempo é que quando o backlog falha, há falta de clareza sobre quem decide o que entra nele e em qual ordem.

Backlog é um termo comumente usado nos métodos ágeis de gestão para se referir à lista de tarefas necessárias para a entrega de um produto. No entanto, não se trata simplesmente de um sinônimo – o termo engloba técnicas de organização e priorização que o tornam um dos artefatos mais importantes na realização de um projeto ágil bem sucedido.

No livro "Scrum: A arte de fazer o dobro do trabalho na metade do tempo", de Jeff Sutherland, o termo backlog é definido como:

"Uma lista de tudo que precisa ser construído ou realizado para que a visão (do projeto) se torne realidade."

Navegue pelo conteúdo

1. Quais itens fazem parte de um backlog?
2. Para que ter um backlog ao invés de uma lista de tarefas tradicional?
3. Organização, priorização e refinamento de itens
4. Como quebrar estórias grandes: o método SPIDR
5. O ciclo de um item no backlog – da ideia inicial à funcionalidade entregue

No contexto do desenvolvimento de software, em que criar um backlog é bastante comum, podemos pensar, inicialmente, em quatro tipos de itens:

• O conjunto de desejos dos stakeholders do projeto, que costumam se dividir entre funcionalidades e interfaces do sistema;
• As atividades técnicas mapeadas pelo time de desenvolvimento e que são indispensáveis para o bom funcionamento do software;
• Itens de melhoria contínua que surgem de acordo com os testes de funcionalidades e costumam estar relacionados a questões de usabilidade e performance;
• Os conhecimentos específicos que precisam ser adquiridos para desenvolver o produto.

O objetivo do backlog é gerar mais transparência durante o desenvolvimento de um projeto, nivelar o entendimento de todos os envolvidos sobre o que é preciso fazer e, especialmente, maximizar a possibilidade de constantes avaliações e adaptações das tarefas durante todo o processo.

Para que cumpra seu objetivo, um backlog de produto precisa se estruturar a partir de certas regras:

• ‍Ele deve ser a única fonte de demandas e tarefas do projeto. Tudo que precisa ser feito deve estar listado e ordenado nele;
• O backlog deve ser administrado por uma única pessoa. No scrum, esse profissional costuma ser o Product Owner – mas não se preocupe com o termo, neste texto te explicamos tudo sobre ele;
• Muitos times trabalham em conjunto para entregar um produto. Por isso, o backlog pode ser organizado por atributos que agrupam itens de desenvolvimento, itens de design, itens de gestão do projeto e assim por diante;
• Os itens do backlog devem conter descrição, ordem, estimativa e valor, e só são considerados concluídos quando podem ser efetivamente testados ou demonstrados;‍
• O backlog é vivo e nunca está completo. Um bom produto é aquele que melhor atende às necessidades dos usuários, e isso exige que seu projeto seja maleável. Por isso, o backlog está sempre em aberto, se transformando a partir dos constantes testes e feedbacks que reinformam as prioridades e os valores que o produto realmente precisa entregar.

Na prática, um dos maiores desafios que encontramos em projetos é a tendência de transformar o backlog em uma lista de desejos acumulados: tudo entra, pouca coisa sai, e o time perde a referência do que realmente importa. O refinamento constante não é um ritual burocrático: é o que mantém o backlog vivo e útil. Nos projetos da Caiena, reservamos tempo fixo de refinamento em todo ciclo justamente porque sabemos que um backlog desatualizado cria mais confusão do que uma lista informal. Para decidir a ordem de prioridade de forma mais objetiva, muitos times recorrem a frameworks como o WSJF.

Os itens de um backlog são partes da entrega de um produto. Esses itens começam como uma ideia ampla e pouco detalhada que deve ser desdobrada em pontos cada vez menores e mais específicos.

Itens em diferentes etapas de detalhamento possuem diferentes nomenclaturas e características:

- Um item grande é comumente chamado de épico ou tema. Possui uma entrega de valor clara, ainda que pouco detalhada, e algumas hipóteses quanto à solução que deve gerar. Nessa etapa, não se sabe "como" ele será construído nem do que ele é composto;

- Um item médio é chamado de funcionalidade ou recurso. Nessa fase já há um maior conhecimento sobre a entrega de valor e de "como" ela será construída. Também constroem-se protótipos para validar as ideias e depois desdobrá-las em pedaços menores;

- Os itens pequenos são chamados de estórias de usuário – são itens que estão prontos para entrar em desenvolvimento. Toda a equipe técnica participa da preparação desses itens, pois é o time que compreende a complexidade e o tempo de trabalho que as tarefas de desenvolvimento exigirão.

Veja na imagem uma representação do que é chamado de refinamento do backlog:

Uma das dificuldades mais comuns que encontramos nos times de desenvolvimento ágil é a de "quebrar" estórias grandes em estórias menores. Quando isso não acontece, alguns problemas tendem a se repetir:

• O valor demora muito mais para chegar ao usuário — o que, dependendo da estratégia de negócio, pode ser desastroso;
• Aumentam as chances de entregar o valor incorreto, já que decisões complexas são tomadas de uma só vez, sem feedbacks rápidos dos usuários;
• A motivação do time diminui, porque quanto mais tempo se passa numa única estória, menos motivado o time fica.

E quando o time tenta quebrar as estórias sem uma técnica eficiente, é comum levar tempo demais no processo, ou quebrar a estória grande em partes que dependem umas das outras (como separar back-end e front-end), que sozinhas não entregam valor ao usuário.

Um método simples e eficiente para isso é o SPIDR, apresentado por Mike Cohn na série Better User Stories. São 5 técnicas, cada uma usada em um cenário diferente:

• Spike: o time não tem o conhecimento necessário para implementar a estória – nesse caso, quebra-se a estória grande em duas: uma para estudo e construção de conhecimento, outra para implementação;
• Paths: existem várias alternativas possíveis para atingir o objetivo da estória – quebra-se de acordo com essas alternativas;
• Interfaces: diferentes dispositivos ou interfaces com outros sistemas são o alvo – quebra-se por dispositivo ou interface;
• Data: há muitos dados a considerar – quebra-se de acordo com o recorte de dados relevante;
• Rules: há muitas regras de negócio – separam-se ou aliviam-se as regras, sempre alinhado com todos os envolvidos para garantir que o usuário final não seja prejudicado.

Um exemplo real: um projeto de gestão de educação de uma rede estadual tinha a seguinte estória no backlog, estimada em 100 story points — sinal claro de que era grande demais para entrar em desenvolvimento como estava:

[100] Como Professor, gostaria de acessar meus diários de classe, tanto via Desktop quanto via Smartphone, para realizar os registros relacionados às minhas turmas

O time não tinha as informações necessárias para implementá-la de uma vez. Por isso, aplicamos as técnicas do SPIDR em sequência:

1. Spike – adicionamos uma estória de pesquisa (8 pontos) para entender o comportamento dos diários de classe existentes antes de seguir;
2. Data – descobrimos que havia três tipos de diário, variando pela Modalidade/Etapa da turma. Quebramos a estória grande em 3 menores (40 pontos cada);
3. Paths – cada uma dessas ainda podia ser quebrada pelos caminhos de preenchimento do diário (frequência, aula, avaliação), chegando a estórias de 20 pontos;
4. Interfaces – cada uma foi quebrada de novo por dispositivo (Desktop ou Smartphone), chegando a 8 pontos por estória;
5. Rules – mesmo quebradas, a exigência inicial era entregar tudo de uma vez (144 story points somados). Analisando os dados, vimos que 70% dos professores eram de turmas do Ensino Fundamental - Anos Finais, Ensino Médio ou EJA. Negociamos com o cliente para priorizar essa fatia primeiro, focando em um único dispositivo.

O resultado: entregamos valor rápido para 70% do público-alvo, e o desenvolvimento seguiu orientado pelos feedbacks reais de quem já estava usando a primeira versão – o que evitou que decisões erradas só fossem corrigidas lá na frente. Veja esse caso completo nesse conteúdo.

Itens de diferentes tamanhos e em diferentes etapas de detalhamento coexistem no backlog. O Product Owner realiza o trabalho constante de analisar ideias ou demandas abrangentes que chegam tanto das equipes do projeto quanto dos stakeholders, compreender o valor e a complexidade de cada uma e coordenar o processo de desdobramento do item em tarefas mais específicas.

Então, os itens do backlog do produto começam como uma tarefa grande, complexa e pouco detalhada (chamada de "épico" ou "tema"). A partir do trabalho conjunto dos times envolvidos e dos stakeholders, sempre coordenados pelo Product Owner, esses itens são desdobrados, detalhados e priorizados – muitas vezes organizados em um roadmap – passando para o estágio de funcionalidades e, posteriormente, de estórias.

As estórias são inseridas no backlog do sprint – que é um ciclo de trabalho de curta duração. Cada sprint (ciclo de trabalho) possui seu próprio backlog composto por itens pequenos (estórias) a serem desenvolvidos naquele período.

Ao final do ciclo, os itens do backlog do sprint são demonstrados e testados pelos clientes e, eventualmente, pelo usuários finais do produto. A partir dos feedback, novos ajustes, mudanças e demandas surgem. Eles são analisados e, sempre que faça sentido, inseridos no backlog do produto. Então, assim como os itens iniciais, eles são detalhados, priorizados e inseridos nos backlogs dos próximos sprints.

Esse constante movimento, que é característico das metodologias ágeis com entrega contínua, depende da boa construção e gerenciamento do backlog. E essa abordagem gera produtos que atendem muito melhor as necessidades dos clientes e que demandam menos retrabalho, menos gastos desnecessários e menos tempo de desenvolvimento.