Em um projeto de software ou de mídia digital que use métodos ágeis (Scrum), o product backlog é uma lista de requisitos a serem contemplados no produto final – funcionalidades ou não. O conteúdo dessa lista é definido pelo product owner, representante do cliente no dia-a-dia do projeto, e é constantemente discutido pela equipe, que sugere o acréscimo ou a retirada de itens de acordo com o andamento do projeto.
O product backlog pode ser composto de user stories, desenvolvidas a partir dos requisitos de um projeto, como:
■ Páginas configuráveis pelos usuários, de acordo com suas preferências de conteúdo e layout, de modo que possam personalizar o conteúdo.
■ Mala direta segmentada, organizada pelos remetentes, de modo possam preparar a estrutura de acordo com os perfis dos destinatários.
■ Análise de estatísticas de acesso e de vendas, pelos gestores de projeto, de modo que possam conhecer as demandas dos consumidores.
Um site de comunidade pode precisar de requisitos como:
■ Lista de discussão configurada pelos gestores do site, de modo a criar uma plataforma participativa.
■ Ferramentas de inserção de comentários e conteúdo para os usuários finais, para que possam publicar conteúdo criado por eles/as.
■ Facilitação de criação de soluções coletivas pelos usuários finais, para a criação de um ambiente participativo.
Um site de comércio pode precisar de requisitos relacionados à venda de produtos:
■ Publicação de mostruário dos produtos com animações e perspectivas 3D para os consumidores, de modo que possam conhecer melhor os produtos.
■ Ferramentas de busca inteligentes para os consumidores, de modo que possam localizar melhor os produtos.
■ Ferramentas que favoreçam vendas cruzadas (cross-selling), de modo que os vendedores possam oferecer produtos relacionados aos que o cliente está comprando (como batatas fritas para o comprador de cerveja); ou vendas “de alto nível” (up-selling), apresentação de um produto melhor, localizando-o próximo a outro, mais popular.
■ Realização de promoções online e offline, campanhas de anúncios, blogs corporativos, pelos marketeiros, para o lançamento de campanhas comerciais agressivas.
Além dos requisitos listados nas user stories, os itens do product backlog podem contemplar:
■ A criação de áreas da arquitetura da informação
■ A implementação do layout da interface
■ A edição do conteúdo de uma sessão
■ A implementação de funcionalidades de software e soluções tecnológicas (formatos das informações publicadas, configurações tecnológicas dos usuários, necessidade de bancos de dados, programas de autoria de páginas, imagens, vídeo, áudio, integração com ferramentas de gestão ou de CRM já existentes na organização).
■ A implementação de características de usabilidade, acessibilidade e funcionalidades especiais.
Os itens da lista de tarefas podem ser compostos também por bugs a corrigir, tarefas de trabalho simples, tarefas de registro de conhecimento, requisitos funcionais ou não. Esses itens são identificados por números e priorizados pelo cliente, baseados no valor que têm para o produto e para o cliente final (a numeração é feita de acordo com o grau de prioridade). Os itens mais importantes e de execução mais imediata são detalhados e divididos em subitens, enquanto os que serão realizados em etapas posteriores não incluem subdivisões, que são especificadas e detalhadas mais adiante, ao longo de cada iteração (sprint).
A lista do product backlog não precisa estar completa no início de um projeto, pois cresce na medida em que projeto evolui e seus objetivos vão ficando mais claros tanto para o “dono do produto” quanto para a equipe de projeto. A gestão do product backlog é realizada pelo product owner.
Elementos do product backlog
Os itens do product backlog devem incluir, cada um:
■ Uma identificação com número e/ou código, para que seja seja fácil referenciá-lo com precisão em conversas ou mensagens.
■ Um título ou descrição sumária para a escrita no quadro de tarefas (taskboard).
■ Valor de negócios (relativo, estabelecido pelo dono do produto, ou product owner) – estabelece a priorização dentro de cada iteração, ou etapa, ou ciclo do projeto.
■ Uma descrição detalhada da funcionalidade ou aspecto a desenvolver.
■ O número de pontos, ou a medida do esforço que a equipe vai empregar para a realização – não é definido pelo dono do produto, mas por consenso da equipe de projeto.
■ Teste de aceitação – Marcação do dono do produto se o produto de cada iteração foi aceito (a ser definido em cada uma).
Também a inserção de uma descrição resumida dos macro-processos de trabalho, ou principais user stories, ajuda o cliente a entender como o projeto será realizado.
No início de cada ciclo, o dono do produto (product owner) seleciona os requisitos mais importantes do product backlog, gerando a selected backlog. Durante cada reunião de planejamento de ciclo (sprint planning meeting) este prioriza itens do selected backlog e os submete à equipe. A equipe homologa a escolha e determina que items poderá realizar no ciclo (sprint).
Estes passam do selected backlog para o sprint backlog e cada item é segmentado em uma ou mais tarefas, que então são divididas entre os integrantes do grupo.
O product backlog muda ao longo do projeto, aumenta, diminui, os itens mudam de ordem, mas a ordem não muda durante o sprint que está sendo realizado. Funciona bem em métodos ágeis, porque permite a flexibilização das demandas do cliente e da equipe de projeto.
(Texto publicado em 11.1.2009. Atualizado em 24.1.2017)