---

O que é o Product Backlog do Scrum? A resposta pode surpreender você!

O Product Backlog (Scrum Backlog), ou Scrum Product Backlog, é o elemento central para gerir todos os requisitos conhecidos de um produto Scrum.

Ele reúne o trabalho emergente e ordenado necessário para melhorar o produto e alcançar seus objetivos. Entre os requisitos estão os funcionais, os não funcionais e outras funcionalidades relacionadas à experiência do usuário e ao design da interface.

O Product Backlog contém solicitações de funcionalidades e suas histórias de usuário de alto nível. Também pode incluir requisitos prévios ou complementares do projeto, como criar ambientes de testes e desenvolvimento. Histórias necessárias para corrigir defeitos conhecidos, reduzir a dívida técnica ou melhorar funcionalidades também têm seu lugar no Product Backlog.

Cada produto tem um Product Backlog, compartilhado por todas as equipes Scrum que trabalham nele. O Scrum Product Owner é responsável por sua criação, manutenção e refinamento. O Product Backlog não responde, nem deve responder, como esses requisitos serão desenvolvidos e entregues.

Essa é a função da equipe Scrum. Ela decide e documenta nos Sprint Backlogs as tarefas necessárias para atender aos requisitos. O Product Backlog e o Sprint Backlog são elementos fisicamente separados, embora os itens do primeiro orientem o conteúdo do segundo.

O responsável pelo Scrum Product Backlog é o Scrum Product Owner. O Scrum Master, a equipe Scrum e outras partes interessadas contribuem para uma lista mais ampla de histórias de usuário que conduza o produto ao sucesso.

Trabalhar com um Product Backlog não impede a equipe Scrum de criar e utilizar outros artefatos para gerir o trabalho. Eles podem incluir um resumo dos diferentes papéis de usuário, descrições de fluxos de trabalho, diretrizes de interface, storyboards ou protótipos de interface. Esses artefatos complementam e detalham o conteúdo do Product Backlog, sem substituí-lo.

O Product Backlog é um documento vivo. Assim como o software melhora incrementalmente, o Product Backlog também cresce ao longo do tempo. O framework Scrum não exige, por si só, um processo separado de gestão de mudanças. O Scrum Product Owner cria as primeiras versões do Product Backlog com base em sua melhor compreensão inicial do produto.

Enquanto observa de perto como o produto evolui de Sprint em Sprint e amplia o conhecimento das necessidades do cliente, o Scrum Product Owner acrescenta, remove e refina requisitos no Product Backlog.

O Scrum Product Owner prioriza os requisitos no Product Backlog. Quanto maior a prioridade de um item do Product Backlog, mais detalhes ele deve conter. Assim, a equipe Scrum pode compreender facilmente os requisitos prioritários e criar as tarefas necessárias para implementá-los.

Além disso, os Desenvolvedores dimensionam os itens do Product Backlog conforme necessário; pontos de história são uma técnica opcional. Essas estimativas devem ser refinadas e melhoradas nas histórias prioritárias para prepará-las para o Sprint Planning.

Cada Product Backlog do Scrum tem atributos que o diferenciam de uma simples lista de tarefas:

• Uma história de usuário no Product Backlog sempre acrescenta valor de negócio ou técnico ao cliente, ao responsável pelo negócio e aos usuários finais,
• Todas as histórias de usuário do Product Backlog são priorizadas e ordenadas da maior para a menor prioridade,
• O nível de detalhe de uma história de usuário depende de sua posição no Product Backlog,
• As histórias de usuário são dimensionadas conforme necessário, utilizando uma técnica adequada,
• O Product Backlog do Scrum é um documento vivo,
• O Product Backlog descreve o trabalho do produto; o plano detalhado de execução dos Desenvolvedores pertence ao Sprint Backlog.

Histórias de usuário agregam valor ao cliente, ao negócio e aos sistemas

Cada história de usuário no Product Backlog deve oferecer algum valor ao cliente. Histórias sem valor para o cliente são puro desperdício de recursos e devem ser eliminadas. O Product Backlog pode incluir histórias para:

• Especificar requisitos funcionais e não funcionais,
• Resumir a divisão de alto nível do trabalho necessário para lançar o produto de software,
• Configurar ambientes de desenvolvimento e demonstração fora de produção,
• Corrigir defeitos.

Exemplo de Product Backlog Scrum

Algumas tarefas podem não agregar valor direto à funcionalidade do sistema e aos clientes do negócio. Ainda assim, devem gerar valor aumentando a qualidade, reduzindo a dívida técnica e melhorando a manutenção do produto no longo prazo.

O Product Backlog é um documento vivo

O Product Backlog do Scrum é um documento vivo. Ele muda e evolui ao longo de todo o projeto. Conforme necessário, novas histórias são acrescentadas, e as existentes podem ser alteradas, detalhadas ou até eliminadas. Os requisitos de projetos Scrum já não são congelados no início, como ocorria com a Metodologia Cascata.

Em vez disso, o conjunto final de requisitos do Product Backlog é desenvolvido iterativamente, junto aos incrementos de software que surgem.

Isso difere da engenharia tradicional de requisitos. Ainda assim, essa nova forma de lidar com as necessidades do cliente permite à equipe Scrum maximizar o valor entregue e minimizar o desperdício de recursos.

Diferentes níveis de detalhe

Os requisitos do Product Backlog podem ter diferentes níveis de profundidade e granularidade. Somente os requisitos que serão implementados nos próximos Sprints devem receber uma definição mais detalhada. Todas as outras histórias devem permanecer em alto nível e ser trabalhadas apenas no momento necessário, antes de a equipe Scrum precisar conhecê-las melhor.

Não faz sentido investir tempo e recursos na especificação desses requisitos, pois alguns podem mudar ou desaparecer antes de serem necessários para implementação. Tratar os requisitos no momento necessário é um dos maiores benefícios que o framework Scrum oferece para lidar com aquilo que nem sabemos que desconhecemos em nossos projetos.

Sem tarefas de baixo nível no Product Backlog

O Product Backlog normalmente descreve o trabalho do produto, em vez da divisão detalhada em tarefas para executá-lo. O Scrum Product Owner define os requisitos junto aos clientes do negócio e às partes interessadas antes de levá-los ao refinamento do backlog ou ao Sprint Planning. Os Desenvolvedores são responsáveis por detalhar as tarefas e organizar seu próprio trabalho.

O Product Backlog do Scrum é ordenado por prioridade

Todas as histórias são priorizadas, e o Product Backlog é ordenado conforme essa prioridade, da maior para a menor. O Scrum Product Owner realiza a priorização com o apoio da equipe Scrum. Valor agregado ao negócio do cliente, custos, riscos e dependências estão entre os fatores mais considerados nesse trabalho. Essa priorização permite ao Product Owner decidir o que a equipe deve desenvolver e entregar a seguir.

Dimensionar os Itens do Product Backlog

Os Desenvolvedores podem dimensionar os itens do Product Backlog utilizando uma técnica acordada, como pontos de história numa escala do tipo Fibonacci ou tamanhos relativos S/M/L/XL/XXL. O Scrum não exige uma escala específica nem uma estimativa para cada item distante. Este material abordará isso mais adiante. Essas estimativas influenciam o planejamento da capacidade dos Sprints, o conteúdo do Sprint Backlog e os planos de lançamento.

Como trabalhar com o backlog

O Product Backlog precisa de cuidado e atenção regulares. Deve ser gerido com cuidado porque é a fonte confiável para compreender a essência do seu produto de software.

No início de um projeto, ele contém muitas histórias de alto nível que podem ou não ser muito relevantes para o sucesso do projeto. À medida que o projeto avança de Sprint em Sprint, o Scrum Product Owner e a equipe aprendem mais sobre ele.

Consequentemente, o conteúdo do Product Backlog reflete cada vez melhor o produto e o aprendizado da equipe.

Após essa organização inicial, o Product Backlog precisa de manutenção contínua. Essa manutenção envolve:

• Descrever e acrescentar novos requisitos à medida que são descobertos. Requisitos existentes podem ser alterados ou removidos conforme necessário,
• Ordenar (priorizar) o Product Backlog. As histórias mais importantes, com maior prioridade, são colocadas no topo,
• Preparar as histórias prioritárias para as próximas reuniões de Sprint Planning, geralmente durante o refinamento do backlog,
• Estimar ou reestimar as histórias do Product Backlog, geralmente durante o refinamento do backlog.

O Scrum Product Owner é responsável por garantir que o Product Backlog esteja sempre em boas condições. Sua manutenção, porém, é um processo colaborativo. Uma parte razoável da capacidade dos membros da equipe Scrum deve ser reservada para o refinamento contínuo do Product Backlog, além do tempo necessário para os eventos Scrum.

Essa manutenção colaborativa do Product Backlog também ajuda a esclarecer os requisitos e a conquistar o envolvimento dos membros da equipe no produto de software em desenvolvimento.