Guia Scrum | 18. O que é o Product Backlog?

O Product Backlog é a única fonte de tarefas executadas pelo Time Scrum. É uma lista de funcionalidades e melhorias planejadas do Produto. Sua forma é mutável e nem todas as tarefas incluídas no Product Backlog serão concluídas. Evolui durante as discussões com os Stakeholders. Também é constantemente aprimorado. Isso significa que quanto mais próximo do prazo, mais detalhada a tarefa se torna.

O que é o Backlog do Produto? - índice:

1. Introdução
2. O que o Product Backlog contém?
3. A forma do Product Backlog
4. Melhoria do Backlog do Produto
5. Resumo

Introdução

Product Backlog é o maior dos artefatos do Scrum. Ele reflete o status do trabalho em um Produto em relação ao Objetivo do Produto. Por outro lado, quando o trabalho em um Produto é concluído, seu Backlog se torna uma lista completa das tarefas realizadas pelo Time Scrum para criar o Produto. No entanto, não contém soluções técnicas detalhadas.

O que o Product Backlog contém?

O Product Backlog é criado durante as reuniões do Product Owner com os Stakeholders. O Product Owner é o único proprietário e a pessoa responsável por esta fonte de tarefas.

A linguagem de negócios caracteriza as entradas no Product Backlog. Em outras palavras, eles descrevem o valor do Produto do ponto de vista dos Stakeholders.

As descrições de tarefas incluídas na lista de tarefas precisam de coerência e clareza. Eles contêm funções e melhorias do Produto geralmente apresentadas na forma de Histórias de Usuário às quais dedicamos uma entrada separada. Aqui vamos apenas mencionar que estas são descrições de funcionalidades parciais do produto respondendo às perguntas sobre os seguintes problemas:

• O escopo das modificações do produto
• O objetivo de modificar o Produto
• O tipo de usuário para o qual essa modificação ocorre

A forma do Product Backlog

A ordem das tarefas incluídas no Product Backlog muda à medida que o Produto se desenvolve. Enquanto trabalha nele, o Time Scrum molda e aprimora suas funcionalidades. Ao encontrar obstáculos, suas ações implementadas permitem que todos pensem e definam soluções futuras adequadas, e estas também mudarão de acordo com novos obstáculos imprevistos. Portanto, não há uma ordem clara e definida de ações, tudo é mutável. A melhoria do Product Backlog visa a sua contínua atualização e preparação para as próximas tarefas. Por esta razão, é contínuo.

Tarefas com um prazo distante são geralmente grandes e genéricos. Sua descrição não contém detalhes, mas apenas um esboço da funcionalidade que deve ser realizada. Também é possível encontrar tarefas entre eles que nunca terminarão.

As entradas no Product Backlog podem apresentar soluções alternativas. E também as ideias do Cliente que podem ficar desatualizadas, não rentáveis ​​ou por algum outro motivo nunca entram na fase de implementação. É por isso que o Product Backlog às vezes é chamado de brincadeira de “Lista de desejos do cliente”.

Outra razão para mudanças na forma do Product Backlog é a redefinição de soluções. Às vezes, um determinado problema já foi resolvido ao criar outra funcionalidade do produto. Ou a funcionalidade esperada tornou-se redundante devido a alterações em outras soluções.

Uma das atividades básicas durante a melhoria do Product Backlog é dividir as tarefas contidas no Product Backlog em partes. Graças a isso, o esboço geral da funcionalidade é apresentado na forma de unidades menores, mais detalhadas e definidas com precisão.

As tarefas projetadas para uma implementação mais próxima tornam-se mais detalhadas. Eles também se tornam menores, contendo detalhes de soluções. Os detalhes surgem durante o desenvolvimento do produto. E graças ao conhecimento do estado atual do Produto e das expectativas atuais dos Stakeholders, o Product Owner complementa as próximas tarefas com sua descrição, ordem e tamanho. Em seguida, seleciona as tarefas melhor descritas para o próximo Sprint Backlog.

Melhoria do Backlog do Produto

Enquanto trabalha em um Produto, o Product Owner modifica e detalha o Product Backlog em cooperação com a Equipe de Desenvolvimento. Seguindo as sugestões do Product Owner, durante o Sprint Planning, a equipe seleciona as funcionalidades a serem implementadas a partir do Product Backlog. Eles são então movidos para o Sprint Backlog e divididos em tarefas a serem concluídas. As tarefas movidas para o Sprint Backlog são descritas em linguagem técnica, que é a mais útil para Desenvolvedores.

O tamanho da tarefa é uma métrica importante do ponto de vista da equipe de desenvolvimento. Sua estimativa adequada se torna especialmente crítica ao selecionar User Stories do Product Backlog para o Sprint Backlog.

A equipe de desenvolvimento aprende com o tempo a estimar corretamente o tempo e o esforço necessários para concluir uma história de usuário específica. Isso é expresso em dias, horas-homem ou Story Points e fornece uma estimativa de um valor chamado Team Velocity.

Resumo

O Product Backlog é uma lista continuamente aprimorada de tarefas que levam ao Objetivo do Produto. O conteúdo do Product Backlog geralmente é expresso na forma de User Stories. E quanto menor o tempo restante para concluir uma tarefa, mais:

• A descrição do trabalho é mais detalhada
• O escopo da tarefa é menor
• O escopo da tarefa é melhor definido

O Time Scrum cuida das tarefas. O Product Owner gerencia e modifica o Product Backlog.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto