O que é o Product Backlog no PMBOK 8?
O Product Backlog — mantido com o mesmo nome em português no contexto ágil — é uma lista priorizada de todo o trabalho identificado para um produto, representando os requisitos funcionais e não-funcionais ordenados por valor para o negócio. No PMBOK Guide, Eighth Edition, o Product Backlog é reconhecido como uma saída das abordagens adaptativas e aparece no contexto da gestão do escopo em projetos ágeis e híbridos.
O PMBOK Guide, Eighth Edition descreve o Product Backlog no contexto adaptativo:
Cadastre-se para navegar sem anúncios e participar do Project Together →
“In adaptive approaches, a product backlog or similar artifact serves as the scope definition for the project. The product backlog is a prioritized list of work to be done to develop the product. It evolves throughout the project as the team learns more about the product and the customer’s needs. The product owner is responsible for the product backlog, including its content, availability, and ordering.”
— PMBOK Guide, Eighth Edition (2025)
O Product Backlog é o equivalente ágil da combinação de Declaração do Escopo + EAP em abordagens preditivas — mas com uma diferença fundamental: ele é um artefato vivo, continuamente refinado e reordenado conforme o time aprende mais sobre o produto e as necessidades do cliente.
Estrutura do Product Backlog
| Nível | Nome | Descrição |
|---|---|---|
| Estratégico | Épicos (Epics) | Grandes iniciativas ou funcionalidades de alto nível — decomposta em features e histórias |
| Tático | Features | Grupos de histórias de usuário que juntas entregam uma capacidade significativa ao produto |
| Operacional | Histórias de Usuário (User Stories) | Unidade básica de trabalho — descrição de valor do ponto de vista do usuário, com critérios de aceite |
| Técnico | Tasks / Tarefas | Atividades técnicas específicas para implementar uma história — surgem durante o Sprint Planning |
Atributos de um item do Product Backlog (PBI)
| Atributo | Descrição |
|---|---|
| Descrição | O que deve ser desenvolvido — tipicamente no formato de História de Usuário: “Como [usuario], quero [funcionalidade], para [beneficio]” |
| Prioridade / Ordenação | Posição relativa na lista — os itens mais valiosos e urgentes estão no topo |
| Estimativa (Story Points) | Tamanho relativo do esforço necessário — estimado pela equipe usando Fibonacci, T-shirt sizes ou Planning Poker |
| Critérios de aceite | Condições que devem ser atendidas para que o item seja considerado “pronto” (Definition of Done) |
| Status | Estado atual: backlog, selecionado para sprint, em progresso, em revisão, concluído |
| Valor de negócio | Impacto estimado no cliente ou no negócio — base para a priorização pelo Product Owner |
Product Backlog vs. EAP (Abordagem Preditiva)
| Aspecto | EAP (preditiva) | Product Backlog (adaptativa) |
|---|---|---|
| Definição do escopo | Completa e definida no início — decomposição hierárquica de todo o escopo | Progressiva e emergente — os itens de maior prioridade estão detalhados; os futuros são breves |
| Estabilidade | Mudanças passam pelo Controle Integrado de Mudanças — processo formal | Continuamente revisado e reordenado pelo Product Owner — mudanças são esperadas e bem-vindas |
| Unidade de entrega | Pacote de trabalho — unidade de planejamento e controle de custo e prazo | História de usuário — unidade de valor do negócio, estimada em story points |
| Horizonte de planejamento | Todo o projeto — planejado do início ao fim antes da execução | Rolling wave — sprints próximos detalhados; sprints futuros em alto nível (just-in-time refinement) |
Product Backlog Refinement (Refinamento do Backlog)
O Refinamento do Backlog é o processo contínuo de manter o Product Backlog atualizado, detalhado e priorizado:
| Atividade | Descrição |
|---|---|
| Detalhar histórias | Decompor épicos e features em histórias de usuário específicas, com critérios de aceite claros |
| Estimar | Time de desenvolvimento estima o tamanho relativo de cada história em story points |
| Reordenar | Product Owner ajusta a ordem do backlog com base em feedback, mudanças de negócio ou novas informações |
| Dividir histórias grandes | Histórias muito grandes (épicos) são divididas em histórias menores, implementáveis em um sprint |
| Remover itens obsoletos | Histórias que perderam relevância ou foram substituídas são removidas ou arquivadas |
Product Backlog em abordagens preditivas, adaptativas e híbridas
Abordagem adaptativa (ágil)
O Product Backlog é o artefato central de gestão de escopo em projetos ágeis. O Product Owner é o único responsável por seu conteúdo e ordenação. O backlog é público e acessível a toda a equipe e stakeholders. O Sprint Planning seleciona os itens de maior prioridade do topo do backlog para o Sprint Backlog — o que será desenvolvido no sprint.
Abordagem preditiva (cascata)
Em projetos preditivos puros, o Product Backlog não é usado — a EAP e a Declaração do Escopo definem o escopo. Quando uma equipe de desenvolvimento preditiva adota práticas ágeis parcialmente, pode usar um backlog de melhorias ou de novos requisitos fora do escopo original.
Abordagem híbrida
Em projetos híbridos, o Product Backlog coexiste com a EAP. A EAP define a estrutura macroentregavel do projeto; o backlog define as funcionalidades a desenvolver nas fases ágeis. O gerente do projeto garante que os itens do backlog estejam alinhados com os entregáveis da EAP e dentro do orçamento e prazo do projeto.
5 erros comuns no gerenciamento do Product Backlog
- Backlog sem Product Owner dedicado: um backlog gerenciado por comitê — onde múltiplas pessoas podem mudar a prioridade sem processo claro — é um backlog caótico. O Product Owner deve ter autoridade e responsabilidade únicos pelo backlog. Decisões de prioridade devem ser consistentes e baseadas em valor de negócio claro.
- Backlog com milhares de itens sem priorização clara: um backlog de 500+ histórias em que apenas as 20 primeiras estão detalhadas e as demais são linhas sem critérios de aceite e estimativas é um backlog não gerenciável. O backlog deve ser regularmente refinado — itens obsoletos removidos, itens de alta prioridade detalhados, escopo que nunca será desenvolvido eliminado.
- Não incluir dívida técnica e trabalho de infraestrutura no backlog: refatoração de código, atualização de dependências, melhoria de cobertura de testes — são itens técnicos sem valor direto ao usuário final mas essenciais para a saúde do produto. Esses itens devem estar no backlog e competir pela capacidade do time junto com as funcionalidades de negócio.
- Backlog escondido dos stakeholders: um backlog público e transparente permite que o cliente e o patrocinador entendam o que está planejado, questionem prioridades e ajustem expectativas. Um backlog secreto gera desconfiança e desalinhamento. A transparência é um valor fundamental do ágil — o backlog deve ser acessível a todos.
- Não vincular o backlog a um objetivo de produto claro: um backlog sem Product Goal — sem um objetivo maior que guia o que deve e o que não deve estar no backlog — vira um repositório de pedidos sem coerência. O Product Goal define o norte do produto e orienta as decisões de priorização do Product Owner.
Checklist do Product Backlog
| Item | Verificação |
|---|---|
| Product Owner designado com autoridade clara sobre o backlog? | [ ] |
| Backlog ordenado por prioridade (maior valor no topo)? | [ ] |
| Itens do topo do backlog detalhados com critérios de aceite? | [ ] |
| Estimativas de story points definidas para os próximos sprints? | [ ] |
| Refinamento do backlog realizado regularmente (ao menos uma vez por sprint)? | [ ] |
| Dívida técnica e trabalho de infraestrutura representados no backlog? | [ ] |
| Backlog acessível e transparente para a equipe e stakeholders? | [ ] |
Template e Exemplo de Product Backlog — PMBOK 8
Para facilitar a criação e gestão do Product Backlog em seus projetos, disponibilizamos dois recursos gratuitos para download:
Template oficial PMBOK 8
Planilha Excel de Product Backlog — estrutura hierárquica (épicos, features, histórias, tasks), campos de ID, descrição, critérios de aceite, story points, prioridade e status, cálculo automático de velocidade de sprint e projeção de conclusão do backlog, mapa de releases e dashboard de progresso.
Exemplo real — Projeto de Desenvolvimento de Software (ProjectAdm)
Product Backlog do projeto ProjectAdm — 3 épicos, 12 features e 187 histórias de usuário ao longo de 12 sprints. Inclui histórico de refinamento (42 histórias adicionadas, 28 removidas e 15 modificadas após feedback do cliente), evolução da velocidade de 45 para 72 story points e mapa de releases com 4 versões entregues.
Quer se aprofundar no PMBOK 8?
O PMBOK Guide — Eighth Edition é a referência essencial para entender o Product Backlog e a gestão de escopo em abordagens adaptativas. Adquira agora:
Adquirir o PMBOK Guide — Eighth Edition na Amazon →
Teste seus conhecimentos sobre Product Backlog
Você sabe qual é a diferença entre o Product Backlog e a EAP no PMBOK 8? E quem é o responsável pelo backlog e quais são suas atribuições? Coloque seu conhecimento a prova:
Iniciar Etapa 1 do Quiz Project Together →
Perguntas frequentes sobre o Product Backlog
O que é o Product Backlog?
É a lista ordenada e única de tudo que pode ser necessário no produto — a fonte de trabalho do Scrum Team. É vivo: muda conforme o produto e o contexto evoluem.
Quem é responsável pelo Product Backlog?
O Product Owner. Ele responde pela ordenação, pela clareza e pela transparência do backlog.
O que é o refinamento do Product Backlog?
É a atividade contínua de detalhar, estimar e ordenar os itens — deixando-os prontos para futuras Sprints. Não é um evento formal.
Qual é o compromisso do Product Backlog?
A Meta do Produto: o objetivo de longo prazo que dá direção ao backlog.
O Product Backlog e o PMBOK 8
O Product Backlog dialoga com o Guia PMBOK 8:
- Domínio de Escopo: é onde o “o quê” do produto é priorizado por valor, de forma adaptativa.
- Transparência: um backlog visível e ordenado sustenta a inspeção e a adaptação.
- Focar no valor: ordenar por valor é decidir o que entrega mais resultado primeiro.
Scrum + PMBOK andam juntos ✅
Sua prática nesta aula — Agile Together
Aula 9 do curso Agile Together. Hora de mão na massa: a IA gera seu Product Backlog e você refina.
- Com o ambiente pronto (instalação padrão + passo 1 do menu executado), escolha o passo 2 do menu, “Meta do Produto + Product Backlog”.
- Use o prompt do curso (Cap. 1.7 do Guia ou card Referência): a IA lê o seu OBJETIVO do
.enve preencheMETA_DO_PRODUTO+ 9 histórias[IA]com prioridade e pontos. Revise a resposta, cole no cartão “0. Caixa de entrada” do seu quadro e rode o mesmo passo de novo. - Refine com o passo 3 do menu, “Refinar o backlog”: a IA revisa prioridade, story points e adiciona 3-5 critérios de aceitação por história no formato “Dado X, Quando Y, Então Z”. Revise e rode.
- Abra o board no ProjectAdm e confira: Meta do Produto + 9 histórias refinadas na lista Product Backlog.
📘 Os prompts prontos estão nos cards da lista Referência do seu board (criados pelo passo 1 do menu, “Configurar o quadro”) e no Guia Agile Together. Lembre: refinamento é contínuo — volte a refinar sempre que uma história estiver vaga.
Terminou a prática? Responda o quiz abaixo para concluir a aula — a próxima chega na hora no seu e-mail.
Cadastre-se para navegar sem anúncios e participar do Project Together →
QUIZ
Quer testar o que aprendeu neste artigo?
Uma pergunta de múltipla escolha + uma reflexão prática. Ganhe pontos no Project Together!
💬 Reflexões da comunidade
Projeto de Desenvolvimento de Software
— Virgílio Sopieque · 2 semanas atrás
A priorização das atividades faz toda a diferença. Vou organizar isso no meu time.
— Tiago Oliveira · 3 meses atrás
Como Associado da Amazon, a escritoriodeprojetos.com.br recebe por compras qualificadas. Os links para a Amazon nesta página são links de afiliado; o preço que você paga não muda.
