Um backlog ágil bem priorizado não apenas facilita o planejamento de liberação e iteração, mas também transmite tudo o que sua equipe pretende gastar, incluindo o trabalho interno que o cliente nunca notará. Isso ajuda a definir expectativas com as partes interessadas e outras equipes, especialmente quando trazem trabalho adicional para você, e torna o tempo de desenvolvimento um ativo fixo.
Uma lista de Product Backlog é uma lista de trabalho priorizada para a equipe de desenvolvimento derivada do roteiro e de seus requisitos. Os itens mais importantes são mostrados na parte superior da lista de pendências do produto para que a equipe saiba o que entregar primeiro. A equipe de desenvolvimento não trabalha com o backlog no ritmo do Product Owner e nem está enviando trabalho para a equipe de desenvolvimento. Em vez disso, a equipe de desenvolvimento extrai o trabalho do Product Backlog, pois há capacidade para ele, continuamente (kanban) ou por iteração (scrum).
O princípio dos dois “R”s
O Roadmap e os Requisitos de uma equipe fornecem a base para o Product Backlog. As iniciativas do roteiro são divididas em vários épicos, e cada épico terá vários requisitos e histórias de usuários.
O roteiro e os requisitos de uma equipe fornecem a base para o backlog do produto. As iniciativas do roteiro são divididas em vários épicos, e cada épico terá vários requisitos e histórias de usuários. Vamos dar uma olhada no roteiro de um produto fictício chamado “Comida Express”.
Como o site é a primeira iniciativa no roteiro, queremos dividir essa iniciativa em épicos (mostradas aqui em azul, verde e roxo) e histórias de usuários para cada uma dessas épicas.
O Product Owner organiza cada uma das histórias de usuários em uma única lista para a equipe de desenvolvimento. Podendo optar por entregar um épico completo primeiro (à esquerda). Ou talvez seja mais importante para a aplicação, testar a realização de um pedido, o que exige histórias de vários épicos (à direita). Veja os exemplos abaixo:
O que pode influenciar a priorização de um Product Owner?
- Prioridade do cliente
- Urgência de obter feedback
- Dificuldade de implementação relativa
- Relações simbióticas entre itens de trabalho (por exemplo, B é mais fácil se fizermos A primeiro)
Embora o Product Owner tenha a tarefa de priorizar a lista de pendências, isso não é feito em vão. Product Owners eficazes buscam informações e feedback de clientes, designers e equipe de desenvolvimento para otimizar a carga de trabalho de todos e a entrega do produto.
Mantendo o backlog vivo
Depois que o backlog do produto é criado, é importante mantê-lo regularmente para acompanhar a aplicação. Os Product Owners devem revisar a lista de pendências antes de cada reunião de planejamento da iteração para garantir que a priorização esteja correta e que o feedback da última iteração tenha sido incorporado. A revisão regular do backlog é frequentemente chamada de “backlog grooming” em círculos ágeis (alguns usam o termo refinamento do backlog).
Quando a lista de pendências aumenta, os Product Owners precisam agrupar a lista de pendências em itens de curto e longo prazo. Itens de curto prazo precisam ser totalmente detalhados antes de serem rotulados como tal. Isso significa que histórias completas de usuários foram elaboradas, a colaboração com o design e o desenvolvimento foi resolvida e estimativas do desenvolvimento foram feitas.
Itens de longo prazo podem permanecer um pouco vagos, embora seja uma boa idéia obter uma estimativa aproximada da equipe de desenvolvimento para ajudar a priorizá-los. A palavra-chave aqui é “aproximada”: as estimativas mudarão quando a equipe entender completamente e começar a trabalhar nesses itens de longo prazo.
O backlog serve como a conexão entre o Product Owner e a equipe de desenvolvimento. O Product Owner pode re-priorizar o trabalho na lista de pendências a qualquer momento, devido ao feedback do cliente, estimativas de refino e novos requisitos. Quando o trabalho estiver em andamento, mantenha as alterações no mínimo, pois elas “perturbam” a equipe de desenvolvimento e afetam o foco, o fluxo e o moral.
Depois que o backlog crescer além da capacidade de longo prazo da equipe, não há problema em fechar problemas que a equipe nunca alcançará. Sinalize esses problemas com uma resolução específica, como “fora do escopo”, no rastreador de problemas da equipe, para usar posteriormente em pesquisas.
Pontos a serem observados constantemente
- O Product Owner prioriza o backlog no início do projeto, mas não o ajusta à medida que o feedback chega dos desenvolvedores e das partes interessadas.
- A equipe limita os itens da lista de pendências àqueles voltados para o cliente.
- O backlog é mantido como um documento armazenado localmente e compartilhado com pouca frequência, impedindo que as partes interessadas obtenham atualizações.
Como os backlogs de produtos mantêm uma equipe ágil?
Os Product Owners experientes cuidam rigorosamente da lista de pendências de produtos de seu programa, tornando-o um esboço confiável e compartilhável dos itens de trabalho de um projeto.
Os pedidos em atraso estimulam debates e escolhas que mantêm um programa saudável – nem tudo pode ser a principal prioridade.
As partes interessadas desafiarão as prioridades, e isso é bom. A promoção da discussão sobre o que é importante coloca as prioridades de todos em sincronia. Essas discussões promovem uma cultura de priorização de grupo, garantindo que todos compartilhem a mesma mentalidade no programa.
O backlog do produto também serve como base para o planejamento da iteração. Todos os itens de trabalho devem ser incluídos no backlog: histórias de usuários, bugs, alterações de design, dívida técnica, solicitações de clientes, itens de ação da retrospectiva etc. Isso garante que todos os itens de trabalho sejam incluídos na discussão geral de cada iteração. Os membros da equipe podem fazer trocas com o Product Owner antes de iniciar uma iteração com conhecimento completo de tudo o que precisa ser feito.
Os product owners determinam a prioridade dos itens de trabalho na lista de pendências, enquanto a equipe de desenvolvimento determina a velocidade através da lista de pendências. Esse pode ser um relacionamento tênue para novos product owners que desejam “enviar” trabalho para a equipe. Saiba mais em nosso artigo sobre limites e fluxo de trabalho em andamento.
