Guia Scrum | 40. Nutrição do Backlog do Produto

O cuidado do Product Backlog é uma das principais tarefas de um Product Owner. O processo de cuidado inclui formular, detalhar e adicionar novas User Stories ao Product Backlog. No entanto, a tarefa mais importante do cuidado é garantir que as entradas colocadas no Backlog estejam na ordem correta, ou seja, se tornem priorizadas.

Cuidado do Product Backlog – índice:

1. Introdução
2. Objetivo do cuidado do Product Backlog
3. Erros na manutenção do Product Backlog
4. Manutenção do Backlog vs. métricas usadas no Scrum
5. Resumo

Introdução

O Product Backlog é um dos Artefatos do Scrum. Ele contém uma lista priorizada de trabalho necessário para criar um Produto. Em outras palavras, é uma lista de User Stories necessárias para alcançar o Objetivo do Produto. Você pode encontrar uma descrição detalhada do que são User Stories neste artigo. E aqui estão os detalhes sobre as características e como manter o Product Backlog.

O cuidado do Product Backlog também é conhecido pelos seguintes nomes:

• Priorização do Backlog,
• Refinamento do Backlog,
• Escalonamento do Backlog.

Objetivo do cuidado do Product Backlog

O Product Owner gerencia o Product Backlog. As habilidades-chave incluem priorizar tarefas à medida que a data de entrega se aproxima. Isso ocorre porque o objetivo do cuidado do Product Backlog é garantir que as funcionalidades do Produto venham com o maior valor comercial, ou seja, aquelas mais essenciais do ponto de vista do Cliente, estão no topo da lista de tarefas. E sua descrição é clara e detalhada para que sua implementação possa começar logo na próxima Sprint.

O Product Backlog pode ser atualizado diariamente, se necessário. O Product Owner pode adicionar novas User Stories ao Product Backlog após conversar com as partes interessadas e a equipe de desenvolvimento, ou tirando conclusões e reformulando User Stories já escritas no Product Backlog.

A atualização obrigatória do Backlog é uma das tarefas realizadas durante a Revisão da Sprint. Descrevemos esse processo em detalhes neste artigo. Geralmente, durante essa reunião, a equipe Scrum discute não apenas as tarefas a serem concluídas na próxima Sprint. Ela também especifica preliminarmente User Stories e sua implementação nas próximas duas ou três Sprints. Essa forma de fazer as coisas permite que a equipe Scrum e suas atividades tenham uma visão mais ampla da direção de longo prazo. Isso possibilita pensar nas tarefas atualmente realizadas sob a perspectiva de seu desenvolvimento em Sprints subsequentes.

Erros na manutenção do Product Backlog

Um dos problemas mais comuns em relação ao cuidado do Product Backlog é permitir que ele se expanda de forma incontrolável. Isso ocorre porque, ao trabalhar no Produto, várias funcionalidades e tarefas adicionais propostas tanto pelas partes interessadas quanto pelos membros da equipe Scrum aparecem espontaneamente. Portanto, limitar o crescimento do escopo do Product Backlog (scope creep) é uma das tarefas mais importantes realizadas pelo Product Owner. Os erros mais comuns que os Product Owners cometem dizem respeito a:

1. Desvio do Objetivo do Produto – adicionar muitas ideias ao Product Backlog além do Objetivo Básico do Produto não é uma boa prática, pois reduz muito sua legibilidade. É melhor coletar ideias para funcionalidades adicionais em um documento separado.
2. Duplicação de conteúdo – inserir ideias repetidas ou muito semelhantes de diferentes partes interessadas no Backlog – antes de adicionar outra entrada ao Backlog, o Product Owner deve garantir que a nova entrada não duplique nenhuma das existentes.
3. Falta de uma perspectiva mais ampla – você deve ordenar as entradas do Product Backlog de acordo com seu valor em relação ao Objetivo do Produto. No entanto, tenha em mente que a priorização deve levar em conta as próximas várias Sprints para que as tarefas realizadas em uma determinada Sprint estejam perfeitamente ligadas tanto à Sprint anterior quanto à Sprint imediatamente seguinte.

Você não pode evitar erros desse tipo. No entanto, a conscientização sobre sua ocorrência pode tornar o Product Owner mais cauteloso ao adicionar novas User Stories ao Product Backlog para encontrar o equilíbrio certo. Isso porque também é um erro dar muito corte ao Backlog e eliminar entradas que contêm tarefas semelhantes que diferem. Por exemplo, descrever funcionalidades de Produto semelhantes que diferem significativamente na aplicação.

Manutenção do Backlog vs. métricas usadas no Scrum

O Product Backlog contém uma descrição do trabalho restante ao longo do projeto. No entanto, apenas um Backlog atualizado e regularmente cuidado pode estimar com precisão a proporção da quantidade de trabalho concluído em relação ao total. Para representar a quantidade de trabalho concluído, você deve aplicar o Gráfico de Burndown, sobre o qual escrevemos neste artigo.

Outra métrica popular para descrever o trabalho da equipe Scrum é Velocidade. Você pode medi-la comparando o número de entradas do Product Backlog convertidas em Incremento durante uma única Sprint. Descrevemos a Velocidade em mais detalhes neste artigo.

Resumo

O Product Owner realiza o Cuidado do Product Backlog. Quando o Product Backlog é bem mantido, a equipe Scrum tem uma visão clara do trabalho que resta. Ela também pode obter uma perspectiva mais ampla e voltada para o futuro de como é o caminho para o Objetivo do Produto. É por isso que o Product Owner precisa garantir que as User Stories incluídas no Product Backlog estejam em ordem de prioridade para conclusão. E também que as tarefas a serem concluídas nas próximas Sprints sejam descritas em detalhes minuciosos.

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