Backlog do Produto vs Backlog do Sprint: Principais Diferenças

As listas de pendências são a espinha dorsal dos fluxos de trabalho Ágeis, orientando as equipas desde as ideias até à execução. No entanto, uma armadilha comum é não distinguir entre listas de pendências do produto e listas de pendências do sprint—um erro que pode conduzir a prioridades desalinhadas, sprints ineficientes e equipas frustradas.

Embora muitos de nós tenhamos experiência a trabalhar com software de gestão de listas de pendências, utilizar incorretamente estas duas ferramentas distintas pode causar mais perturbações do que clareza.

Então, como podemos garantir que as nossas listas de pendências trabalham a nosso favor, e não contra nós? Compreender os seus papéis únicos não se resume apenas a definições—trata-se de resolver problemas comuns dos fluxos de trabalho e otimizar a colaboração da equipa. Vamos analisar as suas diferenças e explorar como utilizá-las eficazmente.

O que é uma lista de pendências do produto?

Uma explicação curta e simplificada do que é uma lista de pendências do produto: inclui todas as funcionalidades e atividades nas quais você e a sua equipa de desenvolvimento planeiam trabalhar.

Para uma definição mais estruturada, vamos consultar a Atlassian.

Talvez tenha reparado que as pessoas da Atlassian destacaram dois conceitos importantes ao definir a lista de pendências.

1. É priorizada.

Criar uma simples lista de coisas a desenvolver resultará numa enorme confusão ou num produto incapaz de resolver adequadamente os problemas dos seus utilizadores. Por isso, uma lista de funcionalidades não é realmente uma lista de pendências do produto, a menos que seja priorizada.

2. É derivada do roteiro.

Já vi muitas listas de pendências que eram simplesmente o resultado de todos partilharem as suas ideias de funcionalidades e as adicionarem à lista. Isto resulta numa confusão e num produto que se parece com o monstro de Frankenstein. Se quiser que os itens da sua lista de pendências atinjam um objetivo específico do produto ou do negócio, tem de a criar com base no seu roteiro e na visão do produto.

O objetivo principal de ter uma lista de pendências é criar uma única fonte de verdade para toda a empresa. Deve existir sempre uma única lista de pendências e todos devem consultá-la ao decidir o que fazer a seguir.

Além disso, a lista de pendências do produto é também uma excelente ferramenta para facilitar a priorização por si e pelas suas partes interessadas, uma vez que tem tudo o que precisa de fazer sob a forma de uma única lista.

O que deve incluir uma lista de pendências?

Partindo do princípio de que está a utilizar uma das estruturas Ágeis, a sua lista de pendências do produto será composta pelos seguintes itens:

• Épicos: Funcionalidades de grande dimensão que ajudam a alcançar objetivos específicos do produto, como aumentar a conversão, resolver um problema específico dos utilizadores ou melhorar a sua experiência ao longo do produto. A funcionalidade de comentários do Google Docs é um exemplo disso. Os épicos são normalmente compostos por “subfuncionalidades” mais pequenas, denominadas histórias de utilizador.
• Histórias de utilizador: Pequenas funcionalidades ou elementos de uma funcionalidade que são úteis para os seus clientes. No exemplo da funcionalidade do Google Docs acima, “mencionar alguém num comentário” ou “resolver um comentário” seriam exemplos típicos de histórias pertencentes a esse Épico.
• Tarefas técnicas: Partes do trabalho que a sua equipa de desenvolvimento tem de realizar e que não estão relacionadas com as funcionalidades da sua lista de pendências. Exemplos dessas tarefas são configurar uma base de dados de cópia de segurança, refatorizar um microsserviço ou otimizar a velocidade das consultas.
• Erros: Não é uma verdadeira lista de pendências se não tiver erros. Por muito bem que desenvolva e teste as suas funcionalidades, estes pequenos parasitas acabarão sempre por aparecer. Por isso, tem de os guardar, acompanhar e gerir em algum lugar. A melhor prática é armazená-los na sua lista de pendências e priorizá-los tal como qualquer outro item da lista.

É assim que será uma lista de pendências do produto típica:

P.S. Leia o nosso artigo sobre 3 exemplos de uma lista de pendências do produto bem elaborada se procura mais orientações.

Agora, vamos compreender o papel do gestor de produto no que diz respeito ao trabalho com a lista de pendências.

Quem é responsável por gerir a lista de pendências?

Em suma—o gestor de produto é o deus do backlog. É ele que detém as chaves do que é criado, por que ordem e porquê. O backlog é o seu domínio e, em última instância, é responsável por garantir que se mantém alinhado com a visão do produto, as necessidades dos utilizadores e os objetivos do negócio.

Isso não significa que o gestor de produto seja a única pessoa a mexer no backlog. Os engenheiros, designers e outros membros da equipa podem sugerir ou até adicionar itens, mas quaisquer alterações devem ocorrer sob a supervisão do gestor de produto. Afinal, um backlog caótico conduz a um produto caótico.

As principais responsabilidades do gestor de produto relativamente ao backlog incluem:

• Priorizar o backlog – Garantir que o trabalho mais valioso e impactante é abordado primeiro.
• Refiná-lo com a equipa – Rever, atualizar e decompor regularmente os itens para manter o trabalho claro e executável.
• Comunicar as prioridades e alterações do backlog – Manter as partes interessadas informadas, para que não haja surpresas.

Como o backlog é um documento vivo, está em constante evolução. Surgem novas ideias, as prioridades mudam e algumas funcionalidades são totalmente eliminadas. Esta fluidez é um princípio fundamental do Agile—o backlog deve refletir as realidades mais recentes, e não um plano rígido e desatualizado.

Um backlog bem gerido não é apenas uma lista de tarefas; é uma ferramenta estratégica que ajuda as equipas a criar o produto certo no momento certo. E no centro de tudo isto? O gestor de produto, que detém as chaves.

Criar e gerir um backlog de produto: os conceitos básicos

Começa a criar a versão inicial do backlog assim que o roteiro do produto estiver concluído. Normalmente, retiras do roteiro todas as funcionalidades significativas e blocos de trabalho e transformas-os em épicos no backlog.

Depois, começas a desenvolver os documentos de requisitos do produto para cada um deles e crias épicos com base na decomposição das funcionalidades no teu documento de requisitos do produto.

Mas, como consequência natural do desenvolvimento de produtos, acabarás por alterar constantemente estes épicos, adicionar histórias autónomas e corrigir erros, até obteres um backlog semelhante àquele com que a maioria de nós trabalha. Ou seja, um backlog desorganizado.

No entanto, é bastante fácil manter o backlog se:

• Realizares sessões regulares de refinamento do backlog.
• Dedicares tempo no sprint seguinte à correção em massa de erros e à limpeza do backlog.
• Não permitires que todos adicionem as suas ideias ao backlog sem consultarem primeiro contigo.
• Priorizares constantemente o backlog.
• Utilizares o mapeamento de histórias de utilizador para obteres uma visão clara do que precisa de ser feito.

Quanto ao último ponto, existem duas técnicas principais de priorização que te sugeriria utilizar, com base na minha vasta experiência a experimentar uma dúzia delas.

MoSCoW

Esta é uma técnica bastante simples que agrupa os elementos do backlog nestas quatro categorias:

• Obrigatório: Quando a funcionalidade faz parte de uma jornada central do utilizador e não é possível resolver os seus problemas sem ela. Por exemplo, as listas de reprodução do Spotify são obrigatórias.
• Deveria ter: Uma melhoria significativa da jornada do utilizador. No caso do Spotify, seria a possibilidade de procurar listas de reprodução pré-criadas para o teu estado de espírito ou atividade.
• Poderia ter: Algo que proporciona satisfação ao utilizador, mas cuja ausência não é decisiva. O Spotify poderia utilizar gestos para mudar de música em vez de botões.
• Não terá: Funcionalidades ou iniciativas que tu, as partes interessadas ou a tua equipa consideraram inúteis durante as reuniões de refinamento ou priorização.

Como podes ver, o MoSCoW é uma técnica bastante simples. E essa é uma das razões pelas quais gosto de a utilizar: é muito fácil explicá-la a todas as pessoas presentes e conseguir que também a utilizem ao escolherem tarefas de prioridade baixa ou elevada da lista de itens em que estão a trabalhar.

Kano

Outra técnica simples que permite analisar as funcionalidades em questão a partir da perspetiva das necessidades dos teus utilizadores. Aqui, agrupas as funcionalidades nestas categorias:

• Necessidades básicas: A ausência destas é inaceitável para o utilizador. Num quarto de hotel, seria a presença de lençóis limpos na cama.
• Necessidades de desempenho: Funcionalidades cuja quantidade ou presença aumenta diretamente a satisfação do utilizador. Seria o design de interiores do quarto de hotel ou a presença de serviços de lavandaria ou de pequeno-almoço.
• Necessidades de entusiasmo: A ausência destas não diminuirá a satisfação. Mas a sua presença irá certamente aumentá-la. Seria o origami bonito em forma de cisne feito com a toalha na cama do quarto de hotel.

Eis um gráfico que ilustra a relação entre estes tipos de funcionalidades e a satisfação do utilizador no modelo de Kano.

Em suma, o backlog do produto é a lista de tarefas da equipa que o gestor de produto (ou a equipa de produto) cria e mantém utilizando uma grande variedade de ferramentas e técnicas de gestão de backlogs.

O que é um backlog do sprint?

Agora que a natureza do próprio backlog do produto está clara para nós, vamos compreender em que consiste o backlog do sprint (dica: não envolve exercício.)

A Scrum.org define o backlog do sprint como o subconjunto do backlog do produto que a equipa Scrum escolheu concluir durante o próximo sprint. No âmbito da estrutura Scrum, é um dos artefactos centrais do Scrum com que toda a equipa trabalha.

Como sugere a definição, o objetivo central do backlog do sprint é definir claramente o âmbito do trabalho em que a equipa precisa de se concentrar durante o sprint.

O processo de criação do backlog do sprint ocorre normalmente durante a reunião de planeamento do sprint. Aqui, verá normalmente as seguintes atividades:

1. O gestor de produto define o objetivo do sprint.
2. A equipa começa a escolher uma lista exequível de resultados a entregar que a possa ajudar a alcançar esse objetivo.
3. A equipa divide as histórias em tarefas técnicas e calcula as respetivas estimativas.
4. A equipa analisa a sua capacidade e velocidade de sprints anteriores para validar se o backlog do sprint é exequível.

Ao contrário do backlog do produto, cujo único responsável é o PM, a responsabilidade pela criação e manutenção do backlog do sprint cabe à equipa Scrum. Como são as pessoas que executam as tarefas necessárias para criar as funcionalidades, são as mais indicadas para decidir a dimensão e o âmbito do backlog do sprint.

Ao contrário de muitos outros artefactos do Scrum, que algumas equipas podem decidir ignorar (o que é perfeitamente aceitável: adapta-se o Scrum à equipa e não o contrário), o backlog do sprint parece ser aquele que quase todos utilizam. Há boas razões para isso. Especificamente, o backlog do sprint proporciona:

• Clareza do âmbito: A equipa compreende devidamente o trabalho que se espera que realize durante a próxima iteração.
• Maior concentração: Com um âmbito de trabalho claro e um mestre de Scrum que combate todas as tentativas de adicionar novas tarefas ao sprint, a equipa não tem de se concentrar em nada além dos itens do backlog do sprint.
• Melhor acompanhamento do progresso: Como não entram nem saem itens do backlog do sprint, é relativamente fácil perceber até que ponto a equipa está a progredir em direção ao objetivo do sprint.

Relativamente ao terceiro ponto, a maioria das ferramentas Ágeis inclui ferramentas integradas de elaboração de relatórios do sprint que acompanham automaticamente o progresso da equipa. Um dos relatórios mais populares para esse efeito é o gráfico de trabalho restante.

Este gráfico é composto por duas linhas com tendência descendente. A linha cinzenta representa o progresso ideal hipotético da equipa. A linha vermelha, por outro lado, representa o progresso real. O Jira (a ferramenta apresentada na captura de ecrã) mede estas linhas com base no número total de pontos de história que ainda faltam concluir à equipa. Assim, quando alguém fecha uma tarefa, a linha vermelha desce num valor igual ao dos pontos de história estimados para essa tarefa.

Criar e gerir um backlog do sprint

O processo de criação de um backlog de sprint começa com um backlog do produto que ainda não foi refinado. Os responsáveis pelo produto realizam regularmente reuniões de refinamento do backlog (também conhecidas como reuniões de preparação), nas quais a equipa:

• Faz perguntas ao gestor de produto sobre o design e os requisitos, para compreender claramente o que a equipa de produto espera que construa.
• Questiona alguns dos pontos dos requisitos se forem demorados a implementar ou se resultarem em dificuldades técnicas.
• Atribui a responsabilidade por cada item do backlog ao membro da equipa que considera mais adequado para essa tarefa específica.
• Estima a dimensão da tarefa/história utilizando uma das técnicas mais populares, como os números de Fibonacci associados ao póquer de planeamento.

Partindo do princípio de que a equipa refinou tarefas suficientes para a próxima iteração, realizará uma reunião de planeamento da sprint, na qual se compromete com uma determinada quantidade de tarefas do backlog do produto. No momento em que a equipa assume esse compromisso e inicia a sprint, este grupo de tarefas passa a constituir o backlog da sprint.

Para gerir o backlog da sprint, a metodologia Agile disponibiliza-nos várias ferramentas, incluindo:

• Reuniões diárias, nas quais cada membro da equipa apresenta o seu progresso à equipa e comunica quaisquer impedimentos que o estejam a atrasar.
• Gráficos de evolução e de regressão, que visualizam o progresso geral da equipa.
• Reuniões de demonstração no final da sprint, nas quais a equipa apresenta os resultados do seu trabalho à equipa de produto e recebe feedback acionável sobre o design e a funcionalidade das funcionalidades que desenvolveu.

Por fim, existem as reuniões de retrospetiva. Estas não o ajudam diretamente a gerir o backlog da sprint, mas permitem discutir os processos que irão melhorar a qualidade e a eficiência da sua gestão.

Principais diferenças entre os backlogs do produto e os backlogs da sprint

Para compreender melhor as diferenças entre estes conceitos aparentemente semelhantes, apresento-lhe primeiro uma visão lado a lado das diferenças e, em seguida, explicarei cada elemento com mais detalhe.

Embora a própria visão geral consiga explicar facilmente em que diferem, poderá ainda ter dúvidas sobre aspetos específicos. Por isso, vou analisá-los um por um.

Período de tempo: Os backlogs do produto representam o seu plano a médio e longo prazo, uma vez que refletem o roteiro e a visão do seu produto. Assim, o horizonte de planeamento pode variar entre várias sprints e alguns anos.

Os backlogs da sprint, por outro lado, têm um período de tempo muito curto, uma vez que representam os itens que a sua equipa planeia entregar na sprint seguinte (que normalmente dura 1-4 semanas).

Responsabilidade: Como já referimos, a pessoa responsável em última instância pelo backlog do produto é alguém da equipa de produto (normalmente, o responsável pelo produto atribuído a essa equipa). A equipa Scrum pode contribuir para o backlog, mas só o pode fazer através do gestor de produto.

A situação é diferente com o backlog da sprint. A única forma de um gestor de produto o poder afetar é definindo o objetivo da sprint. Fora isso, é a equipa Scrum que tem autoridade para o criar e gerir.

Nível de detalhe: Uma vez que os elementos de um backlog do produto podem representar o trabalho de vários trimestres ou até anos, não é realista esperar que o gestor de produto tenha todos os elementos descritos em detalhe. Na verdade, desaconselho vivamente essa abordagem, pois existe sempre a possibilidade de acabar por eliminar muitas funcionalidades e seria uma perda de tempo tê-las descrito meticulosamente.

Normalmente, os elementos com maior prioridade terão um elevado nível de detalhe, enquanto tudo o resto terá uma descrição geral.

No entanto, para que as histórias entrem no backlog da sprint, têm de incluir todos os detalhes necessários. Caso contrário, a equipa Scrum recusará implementar as histórias se não tiver uma compreensão clara do que é esperado dela.

Objetivo: O backlog do produto é o “intermediário” entre planos estratégicos muito vagos e detalhes de implementação técnica muito específicos. Serve como ferramenta para expressar os seus planos estratégicos sob a forma de uma lista de tarefas.

Os backlogs da sprint, por outro lado, são altamente táticos por natureza e têm como objetivo fornecer à equipa um plano de ação e um âmbito claros para o curto prazo.

Flexibilidade: Os backlogs do produto são documentos dinâmicos que mudam constantemente. Tendo em conta a sua natureza de longo prazo, não têm outra opção senão mudar com base nas novas prioridades, no feedback dos utilizadores e nas condições do mercado, para que o seu produto continue viável.

Os backlogs da sprint são o oposto absoluto disso. Embora incentive vivamente a evolução constante do backlog do produto, alterar os elementos de um backlog da sprint é totalmente desaconselhável, pois acabará por quebrar todos os compromissos e planos da sua equipa.

Como funcionam em conjunto o backlog do produto e o backlog da sprint

Tal como mencionado, o backlog da sprint é o subconjunto mais preciso e esclarecido do backlog do produto. Continua a considerá-lo parte do backlog até ao momento em que a sua sprint atual termina. Depois disso, as histórias concluídas saem do backlog e as incompletas voltam a entrar no topo da lista de prioridades.

Assim, em termos do fluxo de funcionalidades entre estes dois backlogs, pode não só preencher o backlog da sprint com itens do backlog do produto, como também fazer o contrário.

Independentemente da direção que as histórias tomem, garantir uma transferência fluida é fundamental. Eis aquilo a que sugiro que preste atenção:

• Tudo o que entra no backlog da sprint deve incluir questões em aberto para a equipa Scrum. Caso contrário, tornar-se-á um bloqueio ao progresso da sprint. A melhor forma de gerir isto é criar uma lista de Definição de Pronto (DoR) em conjunto com a sua equipa e segui-la.
• Tudo o que entra no backlog da sprint deve ter estimativas. Caso contrário, os compromissos e planos da sua equipa estarão incorretos. Também será difícil utilizar gráficos de burndown para monitorizar o progresso.
• Ao criar o backlog da sprint, pergunte sempre claramente à equipa se se sente confortável com a carga de trabalho. As pessoas tendem a sobrecarregar-se e acabam por ter sprints parcialmente concluídas.
• Ao retirar itens incompletos da sprint no final desta, aborde sempre o assunto na reunião de retrospectiva. Desta forma, poderá encontrar a ineficiência do processo e eliminá-la.

De um modo geral, é assim que todo o processo se apresenta.

Além das sugestões para ligar estes dois elementos, deixe-me ajudá-lo a gerir corretamente ambos com algumas boas práticas baseadas na minha experiência.

Boas práticas para a gestão do backlog do produto

Ser responsável por um backlog do produto pode ser uma experiência agradável ou terrível, dependendo da forma como o gere. Eis o que faço com base em anos de experiência:

• Limpezas constantes: Encontre a coragem para remover do backlog os itens que têm poucas probabilidades de chegar à fase de desenvolvimento.
• Comunicação com as partes interessadas: Realize reuniões regulares de priorização de alto nível com as partes interessadas. Desta forma, o plano que têm em mente fica alinhado com o que consta do backlog.
• Lista separada para itens com futuro incerto: Por vezes, você ou uma parte interessada terá ideias que podem ou não vir a ser desenvolvidas. Para evitar encher o backlog com essas ideias, mantenha-as numa lista separada. Adicione-as ao backlog apenas quando souber que as vai desenvolver.

Por fim, sugiro que tire partido das muitas ferramentas e modelos disponíveis para um backlog do produto, de modo a acelerar o processo de criação. Eis alguns da ClickUp que pode utilizar.

Caso queira ler mais sobre boas práticas de produto, sugiro que consulte o nosso guia dedicado ao tema.

Boas práticas para a gestão do backlog da sprint

O backlog da sprint representa o âmbito de um incremento específico. Por isso, as sugestões para o gerir corretamente são um pouco diferentes:

• Evite um planeamento excessivo: Os seres humanos são terríveis a estimar as suas capacidades. Se a sua equipa se comprometer com um backlog da sprint consideravelmente maior do que o anterior, deverá ajudá-la a remover alguns itens.
• Resolva os bloqueios diariamente: Ao longo da minha carreira, nunca vi uma sprint decorrer sem problemas (e já acompanhei centenas). Os bloqueios surgirão sempre. E, se não os resolver imediatamente, as probabilidades de concluir a sprint diminuem drasticamente. Por isso, preste muita atenção ao que a sua equipa comunica durante as reuniões diárias.
• Utilize ferramentas especializadas: A Internet está repleta de software criado para melhorar a eficiência e a eficácia dos seus processos Ágeis. Tire partido deles.

Quanto ao último ponto, eis algumas ferramentas com todas as funcionalidades essenciais que pode considerar utilizar.

Atlassian Jira: Ferramenta Ágil repleta de funcionalidades para fluxos de trabalho complexos e equipas de grandes dimensões.

Trello: Ferramenta leve de gestão de tarefas com complementos Ágeis (Kanban e Scrum), ideal para pequenas equipas de startups.

Monday.com: Situa-se entre o Jira e o Trello. É rica em funcionalidades, mas suporta facilmente processos leves e equipas pequenas.

Para saber mais, consulte a nossa lista das melhores ferramentas de gestão de produtos.

Armadilhas comuns e desafios da gestão do backlog

Já perdi a conta ao número de falhas desastrosas que tive ao gerir os meus backlogs ao longo da minha carreira. Embora cometer erros seja inevitável (é assim que se aprende), ainda assim quero destacar alguns erros significativos, na esperança de que os evite (ao contrário de mim).

Achar que sabe tudo: Isto é especialmente válido quando se é júnior (olá, efeito Dunning-Kruger). Lê alguns artigos sobre gestão de backlogs e pensa que sabe fazê-lo melhor do que qualquer outra pessoa. Isto quase sempre conduz a um grande desastre. Por isso, se houver gestores de produto mais experientes por perto, não hesite em pedir a sua ajuda. Em alternativa, também pode consultar os exemplos de backlogs de produto bem elaborados.

Parar de aprender: O mundo do Agile evolui rapidamente. Se deixar de aprender sobre novas práticas e ferramentas, acabará por enfrentar problemas que já têm soluções inovadoras disponíveis. Por isso, inscreva-se em cursos ou webinars sobre Agile e subscreva a nossa newsletter para receber muitos recursos e guias sobre gestão de produtos.

Pensar que os PMs não fazem parte da equipa Agile: Se pensa que os PMs não têm nada que ver com os itens incluídos no sprint, é muito provável que a maioria dos seus sprints falhe. Durante a implementação das histórias, surgem sempre questões e pedidos de esclarecimento relacionados com o produto. Quanto mais rapidamente os resolver, melhor será a qualidade do resultado na revisão do sprint.

Tudo é uma prioridade e o prazo terminou ontem: Também conhecida como “a doença do CEO”, esta é uma indicação de que o seu backlog não tem prioridades definidas. Uma forma simples de atenuar esta situação é ter a coragem de dizer ao seu CEO: “Não temos capacidade, diga-me qual é a mais importante”. Acredite em mim, a maioria dos CEOs irá ouvi-lo e dar-lhe uma prioridade clara.