Os melhores conselhos dos especialistas Scrum e Agile sobre como gerenciar o backlog de seu produto

Primeiro, vamos definir claramente um backlog de produto. O Scrum organiza os projetos em uma série de períodos de trabalho focados chamados Sprints, e cada Sprint geralmente dura duas semanas. Antes do Sprint começar, a equipe e o Scrum Master (que funciona como treinador) criam seu backlog Sprint, que é uma lista do que eles pretendem realizar no próximo Sprint. 

O backlog Sprint é extraído do backlog maior do produto, que é uma lista completa de todos os recursos e funcionalidades que precisam ser adicionados ao produto. O proprietário do produto é responsável por priorizar o backlog do produto. (O proprietário do produto também representa as necessidades do cliente e de outras partes interessadas e orienta o trabalho da equipe de desenvolvimento.) O backlog do produto é classificado verticalmente, de modo que as tarefas mais importantes são listadas na parte superior, e a equipe Scrum geralmente seleciona itens do backlog com base na prioridade. O backlog do produto mudará e evoluirá com o tempo com base em solicitações de usuários, necessidades de negócios e tendências tecnológicas mais amplas.

Como nota lateral, você também pode usar o backlog de um produto em outra estrutura Agile chamada Kanban. Embora Kanban esteja baseado em limitar o trabalho em andamento (WIP) em vez de usar Sprints (Scrum) de comprimento fixo, as informações neste artigo também podem ser aplicadas aos projetos de Kanban.

Um backlog de produto bem construído garante que seu trabalho seja produtivo e valioso, que o produto atenda às necessidades do cliente e que esteja alinhado com os objetivos da sua organização. Assim como na sua lista pessoal de "fazer", você precisa gerenciar constantemente o backlog de seu produto. Esse processo é frequentemente chamado de refino ou preparação do backlog do produto. As prioridades mudam, as tarefas são realizadas e as ideias são descartados. Sem atualizar seu backlog, ele se tornará desorganizado e não o ajudará a se manter no caminho certo.

Para começar a criar um backlog de produto, alguns especialistas do Agile recomendam começar com um roteiro de produto. Este é um plano estratégico que oferece uma perspectiva de longo prazo para o seu produto.  Roman Pichler, um treinador especialista em gerenciamento de produtos Agile, disse que muitos proprietários e gerentes de produtos se concentram demais nos detalhes dos recursos em seus roteiros e não o suficiente em uma grande visão. Ele desenvolveu um modelo de roteiro voltado a objetivos que enfatiza a meta do produto e os recursos necessários para atingir a meta.
 
Embora seu roteiro possa incluir metas de longo prazo para vários lançamentos, o backlog do produto deve se concentrar na listagem de trabalhos para o próximo lançamento em mais detalhes. Os lançamentos futuros devem ser colocados mais baixos e expressos em menos detalhes. Em seguida, pegue as informações do roteiro e traduza isso em tarefas e itens de trabalho. 

Cada produto deve ter seu próprio backlog. Se o seu produto é bastante grande ou parte de um conjunto de produtos interrelacionados, pode ser confuso determinar o que constitui um produto. O especialista da Agile Kenneth> > > Consultorda Innolution, afirma que o objetivo é minimizar o número de equipes componentes e backlogs de componentes, portanto, ele prefere usar um backlog sempre que possível. No entanto, para projetos muito grandes com dezenas ou centenas de equipes, isso não é prático, e nesses casos os backlogs hierárquicos podem ser usados com um backlog para recursos de grande escala e um backlog separado para cada área de trabalho relacionada.

Os itens de trabalho no backlog do produto são frequentemente expressos no que são chamados de histórias de usuário, uma descrição de como o recurso funcionará do ponto de vista do usuário. Uma história de usuário é pequena o suficiente para ser concluída dentro de um Sprint. 

Chuck Kroll, um treinador do Agile que treinou equipes na Fidelity Investments, recomenda uma fórmula tradicional para histórias de usuários:  “Como um (tipo de usuário, como cliente), eu quero (meta) para que (razão)", disse Kroll. “Isso deixa [claro] quem usará o recurso, o que ele agrega e qual valor de negócios ele oferece.”

História do usuário vs. Epic de usuário: Quão detalhados devem ser os itens do backlog?

Uma história muito maior é chamada de "épica" e pode levar vários Sprints para ser concluída. Épicos precisam ser divididos em histórias antes que o trabalho possa começar. 

Mike Cohn, fundador da Mountain Goat Software que oferece treinamentos Agile e Scrum, oferece este exemplo de um épico: uma empresa hoteleira quer que um sistema determine o máximo que pode cobrar por um quarto de hotel, dependendo de variáveis como tarifas dos concorrentes, estação etc. “Como operador de hotel, quero definir a tarifa ideal para os quartos do meu hotel.” Isso se divide em histórias de usuários como "Como operador hoteleiro, quero definir a tarifa ideal para quartos com base nos preços do ano anterior" e "Como operador hoteleiro, quero definir a tarifa ideal para quartos com base no que os hotéis comparáveis aos meus estão sendo cobrados.”

À medida que você prepara histórias de usuários para o backlog do produto, os itens de maior prioridade devem ter mais detalhes para ajudar a equipe a executá-los com precisão. Isso pode incluir diagramas mostrando o fluxo de trabalho de um recurso ou uma descrição de seus detalhes. 
“O conselho mais importante que vejo negligenciado é que os itens de backlog do produto não precisam do mesmo nível de detalhe", disse Cohn. “Os itens que entram na próxima Sprint precisam ser moderados. Os itens mais distantes devem ser menos detalhados.”

Imagine a seguinte história do usuário: Como visitante do site, quero poder comprar uma passagem de avião pelo preço mais barato oferecido ao meu aeroporto de primeira escolha ou aeroportos próximos. Como isso se aproxima do topo do backlog do produto, você deve adicionar detalhes à história do usuário, tais como: a função deve verificar se existem passagens aéreas para todos os aeroportos dentro de 160 km; ele deve me dar a capacidade de classificar as tarifas por distância do aeroporto de primeira escolha, bem como por preço. 

Pichler recomenda que o ciclo de vida do produto seja importante para decidir o quão granular fazer o backlog do produto. Produtos jovens devem ter backlogs mais curtos e menos detalhados, o que permite experimentar novas ideias e mudar seu produto com frequência para otimizá-lo. Por outro lado, produtos mais antigos e estáveis se beneficiam de um backlog mais detalhado, pois você é mais capaz de antecipar como o produto vai evoluir.

O ciclo de liberação é outro fator no atraso do seu produto. À medida que você começa a trabalhar em uma nova versão ou um grande lançamento, há mais desconhecidos e o que você aprender resultará em mudanças potencialmente grandes em seu backlog. Assim, um backlog de produto mais curto e menos detalhado faz sentido no início do ciclo de lançamento, explicou Pichler. 

Bill Wake, um consultor da Agile que agora trabalha com a Industrial Logic Inc, surgiu com um modelo amplamente usado e mnemônico para as características de uma boa história de usuário usando a sigla INVEST:

I - Independente - As histórias não devem se sobrepor e, idealmente, poderão ser implementadas em qualquer ordem.
N - Negociável - A história captura a essência, mas não os detalhes, que são acordados pelos participantes.
V - Valioso - A história oferece um valor claro para o cliente. 
E - Estimado - Você pode avaliar o esforço envolvido. Esta pode ser uma estimativa de tempo ou no que são chamados de pontosde história, uma unidade arbitrária de medição que classifica a complexidade relativa (como XS, S, M, L, XL ou 1, 2, 4, 8, 16). 
S - Pequeno - "Boas histórias tendem a ser pequenas", disse Wake. Isso significa que a história deve ser concluída em (no máximo) algumas semanas de trabalho de 40 horas de uma pessoa dedicada, ou dividida entre os membros da equipe. 
T - Testável - A história do usuário deve ser mensurável ou acionável de alguma forma, de acordo com Ulf Ericsson, fundador e proprietário de produtos da plataforma de testes de TI ReQtest.

Ele ressaltou que nem todos os itens do backlog precisam ser uma história de usuário. “Encontro equipes que acham que cada item de backlog do produto deve ser uma história de usuário. As histórias de usuários são ótimas - quando há usuários por perto. Mas algumas coisas que pertencem a um backlog de produto não são necessariamente diretamente para os usuários. Esses itens não precisam ser escritos como histórias de usuários.” 

Isso incluiria o trabalho no back-end ou em outras tarefas distantes dos usuários. Firewall recomenda descrever essas tarefas usando a sintaxe de desenvolvimento baseado em recursos (FDD) (verbo + resultado + objeto, ou seja. “Validar a senha de um usuário”).
Os quatro tipos de itens comumente encontrados nos backlogs do Scrum são recursos, bugs, trabalho técnico e aquisição de conhecimento. Os recursos geralmente se prestam a serem expressos como histórias de usuário, enquanto os outros itens não. 

Se você está apenas começando, não se preocupe: você não precisa iniciar seu projeto com um backlog de produto perfeito. Comece pensando nas tarefas necessárias e isso fornecerá informações suficientes para o seu primeiro Sprint. Então, você pode expandir o backlog de seu produto à medida que aprende mais sobre o produto, as necessidades do usuário e o feedback.

“Minha principal dica para os backlogs do produto seria mantê-lo simples. É apenas uma estrutura de quebra de produto encomendada", disse Laurens Bonnema, consultora agile da Xebia , na Holanda.

C.J. Boat, um líder de equipe Agile para o mercado de seguros Ensurem, concordou. “Faça expectativas razoáveis! Se você deixar o seu backlog ficar muito grande, ou não organizar adequadamente seu trabalho, os backlogs e sprints podem se tornar tão lotados que vão cair aos pedaços", disse ele. 

Depois de adicionar as tarefas, é hora de pedir o backlog do produto. Coloque o trabalho mais importante acima de um trabalho menos importante. Você pode fazer isso com base na sua classificação de prioridade, fazendo julgamentos à medida que avança em como classificar itens com a mesma classificação de prioridade.

“À medida que você adiciona tarefas ao seu backlog, atribua a elas uma classificação de prioridade inicial", disse Kevin Lonergan, consultor principal de gerenciamento de projetos da Consultoria PMIS da Grã-Bretanha. “Uma prioridade simples de três níveis fará: 1 - fundamental para alcançar as metas de negócios, 2 - útil, mas não crítico, 3 - seria um bônus se esses itens forem feitos.”

Alguns praticantes dizem que um método melhor está ordenando a lista em outros critérios como risco, ROI, custo-benefício, um modelo de balde como MoSCoW (deve ter, deveria ter, poderia ter, não terá), o impacto que uma história tem sobre outra, tempo estimado para implementar ou dependências.

O Método De trabalho mais curto (PDFF) de Xebia, escrito por Donald Reinertsen em "Os Princípios do Fluxode Desenvolvimento de Produtos" e desenvolvido ainda mais por Dean Leffingwell, criador do Scaled Agile Framework. É uma fórmula para priorizar o backlog do produto com base na duração da tarefa e na ponderação do custo do atraso. “Não me deparei com uma maneira melhor de priorizar consistentemente os backlogs em todos os níveis corretamente do que o SMOKINGF", disse Bonnema. As tarefas permanecem no backlog do produto até que estejam concluídas ou até que o proprietário do produto decida que não são mais necessárias. 

Para determinar quando uma história de usuário é concluída e pode ser removida do backlog, as equipes devem desenvolver uma "definição de feito" padronizada.” Este é o critério de aceitação de um recurso que garante que todos os membros da equipe saibam o que é esperado do trabalho que eles entregam. Kelly Waters, autora de All About Agile acredita que "feito" deve significar transportável. Jeff Sutherland, CEO da Scrum Inc., usa a popular frase agile "concluída", o que significa que no final do sprint, a codificação foi concluída e os testes de software são concluídos no nível do recurso sem erros. Quando a definição de concluído de sua equipe é atendida, um item pode ser movido do backlog do produto para a coluna completa.

Agora que você sabe o que é um backlog de produto e o que faz e não pertence a um, aqui está sua lista de verificação para a criação do seu primeiro backlog de produto:

1. O proprietário do produto é responsável pelo backlog do produto. Se for você, é responsável por criar o backlog do produto, mas não precisa ser a única pessoa envolvida. Podem participar membros da equipe Scrum e outras partes interessadas.
2. Lembre-se que o backlog do produto é a lista completa de todas as histórias de usuários e outros itens de trabalho do produto.
3. Pense em todas as tarefas que puder e anote. Seja o mais específico possível e peça informações de todas as partes relevantes da sua organização e feedback do cliente.
4. Produza histórias do ponto de vista do usuário e inclua uma ação e um motivo. (Como _, eu quero _, de modo que_.) Pense em todos os usuários diferentes. Escreva-os em cartões de índice ou use uma ferramenta on-line. Aplique tags para deixar a versão planejada clara.
5. Inclua correções de bugs, aquisição de conhecimento e trabalho técnico.
6. Como proprietário do produto, você avalia sozinho a importância de cada item para a organização que vai de muito alto a muito baixo ou outro método. Você pode pesquisar usuários para ter uma base sólida para essas decisões. 
7. Para cada item de trabalho, também fornece uma estimativa de quanto esforço está envolvido.
8. Classifique o backlog do produto. 
9. O trabalho que a equipe se compromete a enfrentar em um Sprint é o backlog sprint, e isso é separado do backlog do produto. O backlog sprint não é alterado durante o sprint. Os itens são considerados completos e removidos dos backlogs da Sprint e do produto quando são "concluídos.”
10. Quando um novo trabalho chegar, adicione-o ao backlog do produto na posição certa. Ao coletar novas informações, como feedback, você pode excluir ou reordenar itens. 

Quando terminar, você deve acabar com algo assim:

Neste momento, os parabéns estão em ordem se você elaborou com sucesso seu primeiro backlog de produto e fez com que sua equipe Scrum trabalhasse em um lote de histórias valiosas de usuários em um sprint. Mas ainda não é hora de relaxar. 

Uma vez criado, o backlog do produto deve ser continuamente mantido e atualizado. Esse processo, também conhecido como backlog ou refinamento do produto, mantém seu backlog atual com base nas informações do mercado, dos usuários, da equipe de produtos e do gerenciamento da sua organização. Mantendo-se em cima da preparação de backlog, você garante que a equipe de desenvolvimento está sempre colocando seu esforço nas coisas certas, que você está pronto para a próxima Sprint, e que você usa bem seus recursos e entrega o melhor produto possível para seu cliente. 

Uma maneira fácil de se lembrar do objetivo do processo de refinamento do backlog do produto é a sigla DEEP. Seu objetivo é garantir que o backlog do seu produto seja sempre DEEP: 

D - Detalhados corretamente para que os itens na parte superior da lista tenham mais detalhes do que os itens da parte inferior. 
E-Estimado - Cada item de backlog do produto, ou pelo menos os envolvidos no próximo lançamento, deve ser estimado por pontos da história ou hora. À medida que sua equipe consegue mais trabalho sob seu cinto, sua velocidade - a taxa em que termina os itens do backlog do produto - se tornará mais clara e tornará a estimativa mais fácil.
E- Emergente - Isso significa que o backlog do produto é adaptado para novos itens ou informações que surgem.
P-Priorizados - Todos os itens do backlog do produto são encomendados com os mais importantes na parte superior. 

Mesmo com seus melhores esforços para manter o backlog do seu produto funcionando sem problemas, falhas podem surgir. Especialistas do Agile que trabalharam com várias equipes e em vários projetos têm dicas para solucionar problemas e evitar problemas.

O treinador do Agile, Kroll, disse que os problemas mais comuns que ele vê surgem da falta de participação dos patrocinadores do projeto, que precisam estar envolvidos diariamente, e uma tendência para eles pressionarem a equipe para cumprir metas de tempo que não são impulsionadas pelo rendimento real da equipe. A solução é que os gerentes mudem de uma mentalidade de projeto tradicional "planejada versus real" para uma abordagem Agile. 

Jonathan Roger, gerente de projeto e mestre do Scrum na AndPlus, recomenda manter uma "caixa de gelo" na parte inferior do backlog do produto para ideias não priorizadas e sem espaço. “Os proprietários de produtos podem acompanhar os recursos desejados a longo prazo sem a pressão de mantê-los em uma ordem prioritária, e as equipes podem adicionar suas ideias potenciais para a revisão do proprietário do produto. Também serve como um bom ponto de partida para solicitações de recursos de clientes ou partes interessadas.” 

Lonergan, da PMIS Consulting, recomenda uma seleção cuidadosa do proprietário do produto como chave para o sucesso. “Uma pessoa deve desempenhar o papel de proprietário do produto - não um comitê", ressaltou. “Eles são donos do backlog do produto. Certifique-se de que o proprietário do produto impulsione o desenvolvimento do backlog.” 

“O Não. 1 (erro) está, sem dúvida, nomeando a pessoa errada como proprietária do produto devido à falta de autoridade, conhecimento do domínio, falta de tempo, etc", acrescentou Lonergan. 

Do gerenciamento de tarefas simples e planejamento de projetos à gestão de portfólio e recursos complexos, o Smartsheet ajuda a melhorar a colaboração e acelerar a velocidade do trabalho — aumentando sua produtividade. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período. Experimente o Smartsheet gratuitamente hoje mesmo.