O backlog do produto: sua lista de tarefas definitiva

Um backlog do produto saudável é muito parecido com uma pessoa saudável: bem cuidada, organizada e sem nada a esconder.

Dan Radigan Dan Radigan
Buscar tópicos

Um backlog ágil e bem organizado não só torna o planejamento da versão e da iteração mais fácil, como também transmite tudo em que sua equipe pretende trabalhar, incluindo o trabalho interno que o cliente nunca vai notar. Isso ajuda a definir as expectativas com os interessados e outras equipes, ainda mais quando eles levam mais trabalho para você, e faz do tempo da equipe de engenharia um ativo fixo.

O que é uma lista de pendências de produtos?

Um backlog do produto é uma lista de trabalho priorizada para a equipe de desenvolvimento derivada do roteiro e de seus requisitos. Os itens mais importantes são mostrados na parte superior do backlog do produto para que a equipe saiba o que fazer primeiro. A equipe de desenvolvimento não trabalha através do backlog no ritmo do proprietário do produto, e ele não encaminha trabalho para a equipe de desenvolvimento. Em vez disso, a equipe de desenvolvimento retira o trabalho do backlog do produto de acordo com sua capacidade, de modo contínuo(Kanban) ou por iteração (Scrum). 

Dica profissional:

Mantenha tudo em um só sistema de monitoramento de itens. Não use vários sistemas para monitorar bugs, requisitos e itens de trabalho de engenharia. Se é trabalho para a equipe de desenvolvimento, mantenha num único backlog.

Comece com os dois "Rs"

O roteiro e os requisitos de uma equipe oferecem a base para o backlog do produto. As iniciativas do roteiro são divididas em vários epics, ada um deles com vários requisitos e histórias de usuário. Vamos analisar o roteiro de um produto fictício chamado Teams in Space.

Roteiro ágil | Coach Agile Atlassian

Como o site Teams in Space é a primeira iniciativa no roteiro, queremos dividir essa iniciativa em epics (mostrados aqui em verde, azul e azul-petróleo) e histórias dos usuários para cada um desses epics. 

Iniciativas ágeis e epics | Coach Agile Atlassian

O proprietário do produto organiza as histórias dos usuários em uma lista única para a equipe de desenvolvimento. O proprietário do produto pode decidir oferecer um epic completo primeiro (esquerda). Ou pode ser mais importante para o programa testar reservar um voo com desconto, o que exige histórias de vários epics (direita). Veja os dois exemplos abaixo. 

Histórias e epics ágeis | Coach Agile Atlassian

O que pode influenciar a priorização de um proprietário do produto?

  • Prioridade do cliente
  • Urgência para obter feedback
  • Dificuldade relativa de implementação
  • Relações simbióticas entre itens de trabalho (por exemplo, B é mais fácil se fizermos A primeiro)

Embora o proprietário do produto tenha a tarefa de priorizar o backlog, isso não é feito assim, do nada. Proprietários de produtos eficazes buscam informações e feedback de clientes, designers e equipe de desenvolvimento para otimizar a carga de trabalho de todos e a entrega do produto. 

Mantendo a lista de pendências saudável

Depois que o backlog do produto é criado, é importante que ele acompanhe o programa. Os proprietários de produtos devem revisar o backlog antes de cada reunião de planejamento de iterações para garantir que a priorização está correta e que o feedback da última iteração foi incorporado. A revisão regular do backlog costuma ser chamada de "revisão de tarefas" nos círculos ágeis (alguns usam o termo refinamento da lista de tarefas, ou o termo em inglês, backlog grooming).

Quando o backlog fica maior, os proprietários de produto precisam fazer uma divisão em itens de curto e longo prazo. Itens de curto prazo precisam ser totalmente concluídos antes de serem rotulados como tal. Isto significa que histórias de usuário completas foram elaboradas, a colaboração com design e desenvolvimento foi organizada e foram feitas estimativas de desenvolvimento. Itens com prazos mais longos podem ficar um pouco vagos, mas é uma boa ideia ter uma estimativa aproximada da equipe de desenvolvimento para ajudar a priorizar cada um deles. A palavra-chave aqui é "aproximada": as estimativas vão mudar assim que a equipe tiver uma compreensão completa e começar a trabalhar nos itens com prazos mais longos.

O backlog serve como a conexão entre o proprietário do produto e a equipe de desenvolvimento. O proprietário do produto tem a liberdade de alterar a prioridade do trabalho no backlog a qualquer momento, de acordo com o feedback dos clientes, redefinindo as estimativas e novas exigências. No entanto, quando o trabalho estiver em andamento, faça o mínimo de alterações, pois elas atrapalham a equipe de desenvolvimento e afetam o foco, o fluxo e o ânimo. 

Dica profissional:

Se o backlog crescer além da capacidade de longo prazo da equipe, não há problema em fechar itens que a equipe nunca vai conseguir fazer. Sinalize esses itens com uma resolução específica como "fora do escopo" no rastreador de itens da equipe para usar em pesquisas futuras. 

Antipadrões a serem observados

  • O proprietário do produto prioriza o backlog no início do projeto, mas não faz ajustes conforme recebe feedback dos desenvolvedores e dos interessados.
  • A equipe limita os itens do backlog àqueles voltados para o cliente.
  • O backlog é mantido como um documento armazenado no local e compartilhado com pouca frequência, impedindo que os interessados fiquem a par.

Como as listas de pendências de produto mantêm a equipe ágil?

Os proprietários de produto mais experientes cuidam com muito rigor do backlog do produto de seu programa, fazendo dele uma ferramenta de destaque confiável e compartilhável dos itens de trabalho de um projeto.

Os interessados vão questionar as prioridades, e isso é bom. Fomentar a discussão em torno do que é importante faz com que as prioridades de todos fiquem em sincronia. Essas discussões promovem uma cultura de priorização em grupo, garantindo que todos tenham a mesma mentalidade sobre o programa.

O backlog do produto também serve como a base para o planejamento da iteração. Todos os itens de trabalho devem ser inclusos no backlog: histórias dos usuários, bugs, alterações de design, débitos técnicos, solicitações de clientes, itens de ação da retrospectiva, etc. Isso garante que os itens de trabalho de todos sejam incluídos na discussão geral para cada iteração. Os membros da equipe podem fazer concessões com o proprietário do produto antes de começar uma iteração com conhecimento completo de tudo que precisa ser feito.

Dica profissional:

Os proprietários de produto ditam a prioridade dos itens de trabalho no backlog, enquanto a equipe de desenvolvimento dita a velocidade de trabalho no backlog. Isso pode ser uma relação tênue para os novos proprietários de produto que querem "empurrar" trabalho para a equipe. Saiba mais em nosso artigo sobre fluxo e limites do trabalho em andamento.