O que é o Product Backlog

O Product Backlog é a fonte de trabalho para os Developers do Scrum Team e funciona como uma lista priorizada que orienta os Developers através do ciclo de vida do produto. Este artefato abrange tudo o que é necessário para aprimorar e completar o produto, desde novas funcionalidades e melhorias até a correção de bugs e o endereçamento de débitos técnicos. Administrado pelo Product Owner, o Product Backlog é dinâmico e se adapta continuamente às mudanças nas necessidades do negócio e dos usuários, garantindo que cada sprint contribua de maneira significativa para os objetivos finais do produto.

Cada item do Product Backlog é avaliado e estimado pelos desenvolvedores, garantindo que a equipe tenha uma compreensão clara do esforço necessário para cada tarefa. O Product Owner é responsável por detalhar e priorizar os itens do Product Backlog. Os itens são detalhados de acordo com a sua prioridade, sendo os mais valiosos posicionados no topo da lista para serem abordados primeiro. Essa priorização assegura que os recursos da equipe sejam investidos nas áreas que mais agregam valor ao negócio.

O Product Backlog é também um documento “vivo”, evoluindo à medida que novas informações são adquiridas e que o mercado se transforma. Novas ideias podem ser adicionadas, enquanto outras podem ser ajustadas ou removidas, dependendo de sua relevância e impacto. Essa flexibilidade permite que a equipe se adapte rapidamente e mantenha o foco em entregar um produto que não apenas atenda, mas também exceda as expectativas dos usuários e stakeholders.

Exemplo de um Product Backlog e um Lanche

Imaginar o Product Backlog como um lanche nos permite entender como cada camada contribui com uma funcionalidade específica que, em conjunto, resulta em um produto final que satisfaz as necessidades e desejos dos usuários. Cada ingrediente no lanche representa uma funcionalidade distinta que traz um benefício único para o usuário, similar às tarefas listadas no Product Backlog em um projeto de desenvolvimento de software. Vamos explorar esta analogia:

1. Pão Inferior: A base do nosso lanche, equivalente às funcionalidades essenciais e fundamentais do produto. No software, isso pode ser a plataforma de login ou o suporte a múltiplos idiomas, que sustentam todas as outras funcionalidades e garantem que os usuários possam acessar e utilizar o produto com facilidade.
2. Recheio Principal (como carne ou queijo): Representa as funcionalidades centrais que definem a experiência do usuário e trazem o valor principal. No contexto de um e-commerce, isso pode ser o sistema de carrinho de compras ou o processamento de pagamento. São as funcionalidades que os usuários vêm buscar e que direcionam a maior parte da satisfação do usuário.
3. Vegetais (como alface, tomate): Essas camadas adicionam suporte e complementam as funcionalidades principais. Eles podem não ser o motivo principal pelo qual o produto é usado, mas melhoram significativamente a experiência geral. Em software, isso poderia incluir funcionalidades de filtragem avançada de produtos ou recomendações personalizadas, que ajudam os usuários a encontrar os produtos que desejam mais rapidamente.
4. Condimentos (ketchup, mostarda): Essas pequenas adições são semelhantes aos ajustes de usabilidade, pequenas melhorias na interface do usuário ou em funcionalidades que tornam o produto mais agradável de usar, como a capacidade de ajustar configurações pessoais ou o design responsivo que funciona bem em dispositivos móveis.
5. Pão Superior: Este topo do lanche segura todos os ingredientes juntos, assim como as funcionalidades de revisão e finalização do produto, incluindo testes finais de qualidade, otimizações de desempenho e documentação. Garante que o produto está completo, coeso e pronto para ser lançado ao mercado.

Cada camada deste “lanche” traz sua própria funcionalidade que, quando combinadas, criam uma experiência completa e satisfatória para o usuário. Assim como um lanche pode ser personalizado para atender aos gostos específicos de uma pessoa, o Product Backlog pode ser ajustado e repriorizado para melhor atender às necessidades do projeto e dos usuários, garantindo que o produto final seja tanto funcional quanto delicioso em termos de experiência do usuário.

Exemplo de um Product Backlog de um Ecommerce

Considere o exemplo de um e-commerce. O Product Backlog de um E-commerce pode incluir itens como:

1. Mostrar produtos disponíveis para compra
2. Comprar produto
3. Comparar produtos similares
4. Adicionar produto ao carrinho de compras
5. Fechar carrinho de compras
6. Escolher endereço de entrega dos produtos
7. Gerenciar Promoções e Descontos
8. Habilitar Modo Escuro no Site
9. Realizar o checkout expresso
10. Filtrar produtos por disponibilidade.

Relação entre o Product Backlog e o Product Goal

O Product Goal, por sua vez, é a visão a longo prazo do que o produto deve alcançar. Ele orienta a priorização e o refinamento dos itens no Product Backlog, assegurando que cada adição ou alteração esteja alinhada com o objetivo final. Dessa forma, o Product Backlog não é apenas uma lista de tarefas a serem completadas; é uma estratégia dinâmica que se adapta às mudanças do mercado e às necessidades emergentes dos usuários, enquanto permanece focada no cumprimento do Product Goal.

Por exemplo, em um contexto de e-commerce, um possível Product Goal pode ser “Oferecer a experiência de compra online mais rápida e amigável para usuários de smartphones até o final do ano.” Para alcançar este objetivo, o Product Backlog poderia incluir itens como “Otimizar a interface do usuário para operações mais rápidas em dispositivos móveis”, “Implementar um sistema de pagamento simplificado que reduza o tempo de checkout”, e “Melhorar a resposta do servidor durante picos de tráfego”. Cada um desses itens contribuiria diretamente para o cumprimento do Product Goal, garantindo que o e-commerce se destaque pela facilidade de uso e rapidez nas transações móveis.

Itens de Product Backlog devem ser Deep

O conceito de DEEP é crucial para entender como o Product Backlog deve ser estruturado no Scrum. DEEP é um acrônimo que estabelece quatro características essenciais que cada item do Product Backlog deve possuir: Detalhado o suficiente, Estimado, Emergente e Priorizado.

1. Detalhado o suficiente: Cada item no Product Backlog deve conter informações suficientes para que os desenvolvedores compreendam o que precisa ser feito sem ambiguidades. Isso não significa que o item deve ser excessivamente especificado no início, mas deve haver clareza suficiente para permitir estimativas e planejamento adequados.
2. Estimado: Os itens devem ser avaliados em termos de esforço, complexidade e recursos necessários pelos Developers. A estimativa ajuda o Scrum Team a planejar sprints efetivamente e gerenciar expectativas sobre o que pode ser entregue em cada ciclo.
3. Emergente: O Product Backlog é um documento vivo, o que significa que ele evolui à medida que novas informações são descobertas e o entendimento sobre o produto se aprofunda. Itens podem ser adicionados, alterados ou removidos com base no feedback dos stakeholders e nas necessidades do projeto.
4. Priorizado: A priorização é feita pelo Product Owner e baseia-se no valor que cada item traz para o produto final. Os itens mais importantes e de maior valor são colocados no topo do backlog para serem desenvolvidos primeiro, assegurando que o desenvolvimento esteja alinhado com os objetivos estratégicos do negócio.

Por exemplo, no Product Backlog do e-commerce, um item do backlog como “Realizar o checkout expresso” precisaria ser detalhado o suficiente para incluir especificações de segurança e usabilidade, estimado com base na complexidade da integração com diferentes prestadores de serviços financeiros, emergente à medida que novas necessidades de pagamento são identificadas, e priorizado alto devido ao seu impacto direto na capacidade dos clientes de realizar transações no site.

Itens do Product Backlog devem ser INVEST

Os itens no topo do Product Backlog estão mais próximos de serem desenvolvidos e por isso eles precisam estar bem descritos. Para que os itens tenham uma alta qualidade, eles devem ser aderentes aos princípios do INVEST, um acrônimo que orienta o desenvolvimento de itens de backlog eficientes e gerenciáveis. INVEST significa Independente, Negociável, Valioso, Estimável, Pequeno e Testável, características que garantem que cada item possa ser desenvolvido de forma eficaz dentro de um ciclo de sprint.

1. Independente: Os itens no topo devem ser autocontidos, o que minimiza as dependências entre tarefas e simplifica o planejamento e a implementação. No contexto de um e-commerce, por exemplo, desenvolver um novo gateway de pagamento deve ser um projeto independente, sem necessitar de alterações simultâneas em outros sistemas.
2. Negociável: Um bom item de backlog não é uma prescrição rígida, mas sim uma descrição de uma necessidade. Isso permite que os desenvolvedores, stakeholders e o Product Owner discutam e ajustem o requisito para encontrar a melhor solução técnica e de negócios. Por exemplo, ajustar o design do carrinho de compras para melhorar a experiência do usuário pode envolver várias abordagens negociáveis.
3. Valioso: Cada item deve entregar valor claro e direto aos usuários ou ao negócio. No e-commerce, uma funcionalidade como “checkout expresso” claramente agrega valor ao reduzir o tempo de transação para o usuário, melhorando a conversão de vendas.
4. Estimável: Os itens devem ser claros o suficiente para permitir uma estimativa realista de esforço, o que facilita o planejamento e a gestão de expectativas. Uma funcionalidade como “integração com sistema de pontos de fidelidade” precisa ter requisitos bem definidos para uma estimativa precisa.
5. Pequeno: Itens grandes são mais complexos de gerenciar e correm maior risco de não serem concluídos dentro de um sprint. Eles devem ser decompostos em partes menores, como dividir a reformulação de uma página de produtos em várias pequenas atualizações.
6. Testável: Finalmente, cada item deve ter critérios claros para testes para confirmar sua conclusão. No desenvolvimento de um recurso como filtros avançados de pesquisa, os critérios podem incluir a precisão da filtragem e a resposta do tempo de carregamento.

Ao aderir aos princípios do INVEST, os itens no topo do Product Backlog no contexto de um e-commerce são preparados para entrega rápida de valor, com clareza suficiente para desenvolvimento, testes e implantação eficazes. Isso não apenas otimiza os ciclos de lançamento, mas também aumenta a satisfação do cliente com melhorias contínuas e bem-sucedidas.

Exemplo de um Item de Product Backlog

Um exemplo de um item de Product Backlog para um Relatório do Total de Vendas seria o seguinte:

História de Usuário

Eu, como Hillary Gerente de Operações, quero saber o total de vendas e a previsão de vendas para o mês porque preciso melhorar as vendas com maior margem de lucro.

Protótipo

Critérios de Aceitação

Considero este item aceito se:

• Os dados a serem mostrados no relatório devem ser apenas e somente referentes ao último dia com resultados consolidados.
• Devem ser mostrados os dados de volume de faturamento dos 5 parceiros comerciais.
• Os valores devem ter no máximo dois dígitos depois da vírgula.
• Os valores financeiros devem ser mostrados em milhões de reais.
• No ícone (i) devem ser mostradas informações do acordo comercial firmado com o parceiro comercial. Para consultar informações do acordo comercial acesse o arquivo acordoscomerciais.xlsx na pasta acordoscomerciais na intranet.
• Na linha “total” coluna “realizado” deve ser mostrado o somatório do realizado pelos 5 parceiros comerciais.
• Na linha “total” coluna “previsto” deve ser mostrado o somatório do realizado pelos 5 parceiros comerciais tendo vista o modelo preditivo selecionado.
• Na coluna previsto mostrar o resultado do modelo matemático com a menor margem de erro. Assim como a margem de erro do modelo em percentual.
• Mostrar um ícone ao lado da previsão com indicador qual modelo matemático está sendo utilizado para previsão. O ícone informa o tipo de série temporal (d – diário, s – semanal, q – quinzenal ou m – mensal) e qual o modelo está sendo utilizado.
• Cálculo da coluna share deve dividir o valor da respectiva coluna realizado com o valor total da coluna realizado.
• Mostra o relatório em 2 segundos