3 exemplos de backlog de produto bem feitos (+ o que não fazer)

Alguma vez olhou para o seu backlog e teve vontade de apagar tudo e começar do zero? Bem, já tive essa sensação mais do que uma vez, pois criar e manter backlogs de produto não é uma tarefa fácil. Mas, para lhe mostrar como fazer backlogs corretamente e inspirá-lo a organizar o seu, deixe-me partilhar consigo quatro exemplos excecionais de backlogs de produto.

Em que consiste o backlog do produto em Agile e Scrum?

O backlog do produto é um documento vivo que contém todos os itens nos quais a equipa de produto, o scrum master e a equipa de engenharia planeiam trabalhar para desenvolver o produto.

Inclui tudo aquilo de que precisa para desenvolver e manter o seu produto, incluindo novas funcionalidades, tarefas de dívida técnica, melhorias dos processos técnicos resultantes da sua última retrospetiva, tarefas de automatização de QA e muito mais.

A principal característica de um backlog do produto é ser uma lista priorizada, na qual os itens no topo têm a prioridade mais elevada e a equipa deve abordá-los primeiro quando planeia os seus sprints (ou quando tem espaço disponível no seu quadro kanban).

Backlog do produto vs. backlog do sprint vs. roteiro do produto: qual é a diferença?

Na gestão de projetos Agile e, em particular, na metodologia scrum, o backlog do produto não é a única lista de itens que o proprietário do produto cria para a sua equipa de desenvolvimento. Existem também o backlog do sprint e o roteiro do produto. Mas qual é a diferença entre eles? Vamos compreender.

Backlog do sprint: este é um subconjunto do backlog maior e contém apenas os itens que a equipa scrum incluiu no sprint seguinte ou noutro tipo de iteração, na sequência de uma reunião de planeamento do sprint. Os itens aqui estão normalmente bem preparados e contêm pontos de história.

Roteiro do produto: este é um documento de alto nível e visão global que apresenta as principais funcionalidades e marcos do produto. Ao contrário do backlog, que tem uma natureza mais tática e contém descrições de funcionalidades, o roteiro do produto é estratégico e serve para mostrar aos membros da equipa e às partes interessadas qual é a direção do produto e quais são as áreas de foco prioritárias.

Agora que já lhe apresentei devidamente os conceitos essenciais, deixe-me explicar de imediato como gerir o seu backlog do produto (e como, bem, não o fazer).

Como NÃO fazer as coisas corretamente: eis um exemplo horrível de um backlog do produto

Compreender os antipadrões da criação e gestão de backlogs do produto é provavelmente tão importante como aprender as melhores práticas. A razão é que, se não souber que algo é um antipadrão, corre o risco de o incluir no seu backlog e pensar que se trata de algo normal e habitual.

Para analisarmos algumas das práticas que podem diminuir significativamente a qualidade do seu backlog, vejamos o exemplo abaixo.

Voltando ao exemplo. Dedique algum tempo a analisá-lo atentamente.

Parece horrível, não parece? Na verdade, ao olhar para este backlog, a maioria de nós sentirá duas emoções:

1. Repulsa perante a desorganização dos itens deste backlog.
2. Culpa, porque, sejamos honestos, todos nós já tivemos um backlog com este aspeto (eu também, claro).

Vamos agora analisar os problemas encontrados neste backlog.

Sobrecarga de itens do backlog do produto

Reparou que havia 665 problemas neste backlog? Bem, o maior backlog que tive o “prazer” de gerir tinha mais de 2 500 itens.

O problema de um backlog sobrecarregado é que será quase certamente incapaz de se lembrar do que é cada item e da razão pela qual o colocou numa determinada posição/prioridade no seu backlog. Como não faz ideia do que tratam estas tarefas, é pouco provável que as leve para a sua próxima sessão de refinamento, discuta os seus detalhes e as inclua no sprint seguinte.

Assim, acaba por ficar com uma enorme confusão impossível de gerir, que continua a acumular-se infinitamente.

Priorização inadequada do backlog

Outro problema que poderá ter notado nesta lista de backlog é o facto de existirem itens de trabalho com prioridades “Mais baixa” e “Baixa” colocados no topo — acima de itens com prioridade “Mais alta”.

Isto representa o caso típico em que o seu backlog não está devidamente priorizado. Pode haver muitas razões para isso, mas a mais provável é ter reduzido a prioridade de um item com prioridade “Alta”, baixando a sua posição no backlog, mas ter-se esquecido de alterar o campo da prioridade.

Author's Tip

Independentemente da razão pela qual acabou com prioridades desorganizadas, isto é algo que pode prejudicar o seu produto e a sua equipa. Não se esqueça de que o seu backlog deve servir como uma “única fonte de verdade” para todos. Por isso, se houver um item com uma prioridade incorreta definida (por exemplo, uma prioridade mais elevada do que deveria ter), corre o risco de a sua equipa começar a trabalhar nele e ignorar outras tarefas que são mais importantes.

Falta de detalhe

Reparou no item que diz “Quero uma integração perfeita com todas as plataformas de redes sociais”? LOL. Isso nem sequer é uma história de utilizador adequada, considerando o enorme âmbito que pretende abranger. O âmbito é tão vasto que, na prática, deveria ter vários épicos a cobri-lo, com cada épico a conter as histórias de uma plataforma de redes sociais.

Para além do enorme âmbito, o problema com este item (na verdade, com todos os itens deste backlog) é a sua falta de clareza. As histórias de utilizador devem descrever uma experiência e uma ação específicas do utilizador.

Imagine levar esta história para a reunião de aperfeiçoamento do backlog com a sua equipa Agile. Seria confrontado com uma torrente de perguntas sobre quase todos os aspetos da história.

“O que quer dizer com perfeita?” “Qual é o aspeto da integração?” “Com que plataformas de redes sociais estamos a fazer a integração?!”

“Quero tudo, e agora”

Outro sinal de alerta que poderá ter notado no backlog era o facto de 70% dos itens terem uma prioridade “Mais alta”. Esta é outra situação típica quando se baseia exclusivamente nas opiniões das partes interessadas ao definir prioridades (e cada parte interessada considera os seus itens importantes), sem tentar avaliá-los objetivamente e comparar a sua importância com a dos outros itens da lista.

Agora que definimos o aspeto de um backlog inadequado, vamos corrigi-lo e analisar quatro bons exemplos de backlog... para que possa tornar o seu backlog novamente excelente.

3 exemplos de backlogs bem elaborados

Antes de lhe mostrar estes exemplos, quero salientar que não existe uma única forma correta de criar um excelente backlog. O aspeto do seu backlog dependerá da natureza do seu produto, da sua maturidade, da dimensão da sua empresa/equipa, etc.

Na realidade, um excelente backlog é aquele que consegue trazer clareza e alinhamento entre todos relativamente ao âmbito atual e futuro do seu produto.

No entanto, existem formas genéricas de gerir o seu backlog que o tornarão mais organizado e fácil de utilizar por todos. Cada um dos exemplos abaixo representa uma dessas boas práticas.

Exemplo n.º 1: um backlog com secções

Quase nunca é aceitável ter um backlog com centenas ou milhares de itens. No entanto, ter cerca de 100 itens é normalmente bastante comum e normal. Mas mesmo com uma centena de itens no backlog, é fácil esquecer-se do que trata cada um ou deixá-los intocados durante muito tempo sem os adicionar aos próximos sprints.

Para tornar o seu backlog mais organizado, pode considerar dividi-lo em secções.

Alguns gestores de produto gostam de utilizar secções para agrupar itens com base nas suas áreas de foco ou marcos. Pessoalmente, prefiro utilizar etiquetas de Versão, Épico e Componente nas tarefas para este efeito e dividir o meu backlog em secções com base no âmbito dos próximos sprints. 

Esta é uma excelente forma de atribuir um sprint (ou, pelo menos, um calendário de implementação aproximado) à grande maioria dos itens do seu backlog e garantir que nenhuma tarefa fica esquecida.

Outra forma comum de gerir uma lista de pendências com secções consiste em agrupar os itens com base no seu estado de refinamento/fluxo de trabalho (algo em que a IA na gestão da lista de pendências pode ajudar). Neste caso, simplifica o seu processo com as seguintes secções:

• Interação atual
• Pronto para planeamento
• Pronto para refinamento
• Lista de pendências

Neste caso, o que faz é trabalhar na adição de requisitos do produto e descrições para os itens da lista de pendências. Quando os requisitos estão prontos, envia-os para a secção “Pronto para refinamento”, que serve como âmbito para a próxima reunião de refinamento.

Depois de refinar um item, move-o para a secção “Pronto para planeamento”, indicando que está pronto e que a equipa pode incluí-lo na próxima interação.

Exemplo n.º 2: uma lista de pendências com componentes, épicos e versões devidamente posicionados

Segmentar a sua lista de pendências torná-la-á certamente mais limpa e organizada. No entanto, a limitação de utilizar apenas a segmentação é que só pode organizar a sua lista de pendências com base num único critério (por exemplo, as interações, o estado do refinamento, etc.).

Felizmente, as modernas ferramentas de gestão de listas de pendências de produtos oferecem-lhe uma variedade mais ampla de opções para organizar a sua lista de tarefas de desenvolvimento de produtos com base em vários critérios. Veja só esta lista de pendências exemplar.

Não parece bem organizada e agradável à vista? Neste caso específico, tirámos partido das seguintes funcionalidades para tornar a nossa lista de pendências mais fácil de gerir:

Componentes

Este campo/característica descreve tradicionalmente a área do produto onde pretende adicionar a funcionalidade em questão. No exemplo acima, os componentes são os produtos separados que compõem o Grammarly.

Outra forma comum de utilizar componentes consiste em organizar histórias/tarefas com base na tecnologia necessária para criar a funcionalidade. No caso de aplicações Web, por exemplo, pode ter componentes de interface/servidor para ajudar a organizar o trabalho e as dependências entre engenheiros especializados no desenvolvimento do lado do cliente ou do lado do servidor.

Versões/Lançamentos

Com esta característica, documenta todas as funcionalidades e correções de erros que a sua equipa Scrum lançará com uma determinada versão do produto. O acompanhamento de versões na lista de pendências traz dois benefícios extremamente valiosos.

1. Ajuda-o a planear as suas interações e lançamentos. Por exemplo, se planear um lançamento daqui a 2 semanas, durante a reunião de planeamento deve garantir que inclui na interação todas as tarefas destinadas a essa versão.
2. Consegue documentar tudo o que a sua equipa incluiu numa determinada versão e rastrear facilmente os problemas quando algo acontece em produção.

Por exemplo, imagine que as pessoas começam a receber erros de Captcha no seu fluxo de registo na versão mais recente, a 1.3.2. Ao procurar a tarefa com base na qual a sua equipa fez alterações às configurações do captcha, vê que pertence à versão 1.3.1. Isto significa que terá de reverter para a versão 1.3.0 ou fazer uma correção urgente.

Épicos

Bem, não creio que seja necessário explicar o que é um épico e quais são os benefícios da sua utilização. Mas, se quiser aprofundar as melhores práticas e os detalhes minuciosos dos épicos, pode consultar o nosso guia sobre épicos (trocadilho intencional).

Exemplo n.º 3: uma lista de pendências com a quantidade certa de detalhes para cada secção

Esta é uma boa prática que poderá ter encontrado em muitos livros e textos teóricos sobre gestão ágil e gestão de produtos. Embora tendamos a tornar-nos um pouco mais céticos em relação aos conceitos teóricos à medida que ganhamos experiência, este é, na verdade, útil na prática.

A ideia é que os itens no topo devem ter muitos detalhes e, idealmente, já os deve ter submetido a um refinamento da lista de pendências do produto pelo menos uma vez. Por outro lado, os itens no final da lista de pendências devem ter poucos detalhes, uma vez que é muito provável que descubra algo novo sobre o seu produto e os utilizadores finais e que este item se torne obsoleto.

Isto significa que, se o item no topo da sua lista de pendências tiver este aspeto (ou for ainda mais detalhado):

As suas histórias no fundo da lista de pendências devem ter muito menos detalhes e ser semelhantes a esta:

E quaisquer histórias e iniciativas que tenha no meio da sua lista de pendências terão um nível intermédio de detalhe.

Exemplo n.º 4: Eu sei que é óbvio, mas… uma lista de pendências organizada

Eu sei que não é fácil manter a sua lista de pendências organizada. Já passei por isso muitas vezes e sei que parece uma tarefa penosa. No entanto, não rever tudo o que está na sua lista de pendências e não se lembrar de eliminar itens desatualizados são fatores importantes que determinam a qualidade da sua lista de pendências.

Nem sempre é fácil eliminar coisas da sua lista de pendências. Existem funcionalidades realmente interessantes que espera implementar um dia (principalmente coisas desejáveis) e, por vezes, não quer realmente livrar-se delas. Mas, a certa altura, sejamos realistas: sabe que nunca as vai implementar. E, mesmo que o faça, isso significaria que já não tem funcionalidades de alta prioridade, o que, em geral, não é um bom sinal.

Por vezes, são os seus intervenientes que criaram estes itens desatualizados na sua lista de pendências. Antes de os remover, tenta perguntar-lhes se o pedido ainda se mantém e a resposta é quase sempre afirmativa. Bem, se o pedido tiver mais de 6 meses e eles já se tiverem esquecido dele, basta convencê-los de que não é algo urgente (se fosse, teriam feito um acompanhamento várias vezes) e eliminá-lo.

Uma excelente lista de pendências é aquela que funciona melhor para si

Se tivesse em consideração todas as boas práticas aqui apresentadas, teria uma excelente lista de pendências? Bem, elas vão ajudar, mas não garantem a excelência.

Não se esqueça de que o objetivo da lista de pendências é ser uma fonte única de verdade para todos. Por isso, para além destas boas práticas, precisa de ter em consideração as necessidades e o estilo de trabalho da sua equipa e dos seus intervenientes e criar a sua lista de pendências de forma a ajudá-los a manterem-se alinhados.

Este guia sobre excelentes listas de pendências faz parte de uma série mais abrangente sobre tudo o que é Agile. Subscreva a nossa newsletter para receber na sua caixa de entrada, quinzenalmente, mais guias e informações como estas!