Embora o conceito seja claro, construir um product backlog pode ser desafiador para times Scrum. Veja como fazer
Dentro do Scrum, o product backlog é o ponto de partida de onde todas as práticas e ferramentas da metodologia se desenrolam e para o qual todas retornam.
No entanto, apesar de sua relevância, os próprios criadores do Scrum não definem com clareza, em suas obras, como se constrói um product backlog, mas sim o que poderíamos chamar de maneiras de gerenciá-lo. Ken Schwaber e Jeff Shuterland dizem, em seu Scrum Guide:
Os primeiros desenvolvimentos [do product backlog] estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O backlog de produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O backlog de produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. Se um produto existe, seu backlog de produto também existe.
Um bom horizonte para entender o conceito de product backlog, diríamos, mas pouco para quem precisa criar um backlog de produto na prática.
Neste post, então, vamos abordar, a partir das características do product backlog definidas por Ken Schwaber e Jeff Shuterland, como criá-lo e, por fim, boas práticas de gerenciamento.
Product backlog: 9 características
Para responder como construir o backlog de produto, vamos ao começo: as características de um backlog. Os autores do Scrum Guide as definem assim:
1. Backlog de produto é uma lista
A melhor comparação para explicar o conceito de product backlog é a lista de pedidos de um restaurante, que contém tudo o que precisa ser entregue.
2. Sistema puxado
Por ser uma lista de pedidos, o backlog é uma materialização do sistema puxado, tal como o conhecemos no Lean Thinking.
3. Backlog de produto não é completo
Na verdade, ele tem certa completude, normalmente relacionada aos poucos itens necessários para a entrega de um backlog de MVP – Mínimo Produto Viável, mas isso tampouco é necessário para o time começar a trabalhar. O refinamento do backlog de produto é considerado um processo contínuo, que envolve a colaboração de todo o time.
4. Fonte de requisitos
O product backlog é a referência única em relação a requisitos, portanto toda mudança feita no produto parte dele. O backlog de produto é inspecionado após cada sprint na review e na retrospectiva e, se necessário, adaptado a partir disso.
5. O responsável pelo product backlog é o product owner
Como “dono do backlog”, o Product Owner (PO) expressa claramente seus itens, ordena-os para alcançar as metas de negócio, garante sua visibilidade, transparência e compreensão pelo time.
6. O gerente do product backlog é o scrum master
Este membro ajuda o PO a organizar o product backlog de maneira clara e concisa para gerar valor e garantir que o time o entenda.
7. O time de desenvolvimento seleciona os itens do product backlog que serão levados para a sprint
Embora seja o PO que define o objetivo da sprint, quem seleciona o número de itens do backlog de produto necessários para completá-lo é o time de desenvolvimento.
De acordo com Schwaber e Sutherland, somente a equipe “pode avaliar o que pode ser completado ao longo da próxima sprint”. O resultado desse trabalho é o sprint backlog.
8. Priorização
No product backlog, os itens de ordem mais alta devem ser mais claros e detalhados do que os itens de ordem mais baixa, a fim de proporcionar estimativas mais precisas.
9. Itens cancelados
De acordo com o Guia Scrum de Schwaber e Shuterland, no caso de itens do product backlog incompletos, eles devem ser (re)estimados e colocados de volta no product backlog.
Saiba mais: Kanban: conceito, princípios e boas práticas
Como construir um product backlog
Considerando essas características, Paulo Caroli e Fabio Aguiar propõem, no livro Product Backlog Building, uma metodologia para construção de um product backlog. Vejamos algumas premissas da proposta dos autores e, depois, como ela funciona.
Premissas do Product Backlog Building
1. Itens de backlog não são requisitos, mas hipóteses
Em cenários de incerteza, a definição exata de cada requisito pode ser desconhecida. Por isso, ao se fazer um product backlog, assume-se que os itens são hipóteses.
2. Ciclos de desenvolvimento enxutos
Ao assumir que temos hipóteses, automaticamente precisamos validá-las. Em engenharia de software, isso significa colocar o produto na mão do cliente o mais rápido possível. Para isso, será preciso trabalhar com ciclos de desenvolvimento curtos, cujo resultado é sempre software funcional.
3. Trabalho colaborativo
Para que o product backlog seja efetivo, o trabalho de compreensão do produto é coletivo, envolve o alinhamento de cliente e fornecedor em torno dos valores de negócio envolvidos.
4. Ter uma pessoa facilitadora
Esse membro vai reunir o time e conduzir as atividades de construção do product backlog, sobre as quais falaremos abaixo.
Product Backlog Building template Caroli & Aguiar
O template de construção do product backlog de Caroli & Aguiar segue um fluxo de cinco itens, cujo resultado final será visualizado no Canvas abaixo.
Essa dinâmica abre os trabalhos do time e, portanto, os autores recomendam que todo o time participe. Vamos seguir o fluxo, tal como descrito no livro.
1. Contextualize o produto
Este item tem a ver com o nome, problemas resolvidos (estado atual) e expectativas (estado desejado) sobre o produto.
2. Descreva as personas
A persona é uma representação realista do usuário perfeito do produto, detalhada em nível mais profundo que o do público-alvo. Envolve perfil, necessidades e dores, o que ela faz para saná-las e o que espera de um produto ou solução que utilizaria para isso. O mapa da empatia ajuda nessa construção.
3. Entenda as features
Trata-se de uma descrição simplificada do que o produto faz para atender os objetivos e dores da persona.
4. Mapeie os passos de uma feature
Aqui, segundo Aguiar & Caroli, a feature será quebrada em itens menores, em passos ordenados, os quais vão compor o product backlog.
A dinâmica ainda envolve um detalhamento de “como será” o passo, com perguntas, comentários e ideias dos participantes.
5. Identifique os itens do backlog de produto
O resultado do passo anterior serão os itens do backlog para uma funcionalidade. A ação de cada item do backlog de produto também deverá ser descrita, para ganhar contexto e unicidade dentro dele.
Os autores recomendam o modelo ARO – ação, resultado, objeto –, uma história do usuário bem simplificada.
6. Canvas Product Backlog
O resultado de cada etapa de construção do product backlog será registrada no PBB Canvas cujo template vimos acima.
Leia também: Modelos operacionais ágeis: como tornar a tomada de decisão mais eficiente?
Lean inception na construção de backlog
Alinhar a Lean inception ao backlog do produto certamente vai ajudar você e sua equipe a entender melhor o projeto, definir as prioridades e acompanhar de forma mais clara o andamento das sprints.
Afinal, com uma gestão ágil, seus processos se tornam mais coesos e as chances de sucesso no desenvolvimento do produto aumentam. Pois, ao cumprir algumas etapas na construção do product backlog, como contexto do produto, persona e features priorizadas, a lean inception minimiza riscos, esforços e perda de tempo.
Além disso, como seu resultado é um MVP sequenciado, o resultado é uma visão mais ampliada do product backlog.
Assim, ao utilizar uma metodologia ágil em seu projeto você investe em uma equipe mais preparada para lidar com as adversidades que podem ocorrer ao longo do caminho e passa a ter flexibilidade para testar maneiras diferentes de trabalhar, sem um planejamento engessado que bloqueia a inovação.
Refinamento do backlog
Muitas vezes, obter um processo de backlog refinado acaba sendo um grande desafio para o product owner ou o gestor e seu time, devido às dificuldades durante o planejamento das sprints, preparação da equipe e até mesmo quando há um backlog muito grande.
Para superar esses desafios, preparamos algumas dicas e boas práticas que ajudarão no passo a passo do refinamento do backlog, que consiste, basicamente, em detalhar os itens, ordenar e definir as estimativas.
- Identifique e remova os itens desnecessários, que antes pareciam bons mas agora não são relevantes.
- Adicione itens novos que foram descobertos na sprint anterior pelo contato com os stakeholders.
- Melhore a clareza e evite mal entendidos detalhando melhor os itens listados e necessários.
- Divida os itens grandes em itens menores e priorize-os na ordem que devem ser desenvolvidos.
- Adapte as estimativas identificando riscos e obstáculos para itens próximos a implementação.
- Revise e inclua critérios de entrega e qualquer outro item que envolva organizar, limpar e ordenar o backlog do produto.
Em relação ao tempo que deve ser destinado para o refinamento do backlog não há uma definição, entretanto, normalmente não leva mais de 10% da capacidade da equipe de desenvolvimento.
Quanto ao melhor momento para uma reunião de refinamento de backlog, também não há um tempo pré estabelecido.
Vale lembrar que o refinamento do backlog não é realizado em apenas uma reunião. Essa é uma atividade contínua e de responsabilidade não apenas do gerente do produto, mas de toda a equipe.
Veja: Contratação por projetos: quais as vantagens para as empresas?
Product backlog: ainda há muito trabalho pela frente
No começo deste artigo dissemos: o product backlog é onde o trabalho começa e para onde cada ciclo de iteração retorna. Mais que isso, dizemos que sua construção é um trabalho contínuo, revisado ao fim de cada sprint.
Portanto, fazer o product backlog building é um grande começo, mas o trabalho continua.
Partir de metodologias de desenvolvimento de MVP – como a Lean Inception, criada pelo próprio Paulo Caroli, citado neste artigo, e da prototipagem proporcionada pelo Design Sprint - vai acelerar todo esse processo e dar mais efetividade a ele.
Quer ajuda para construir seu MVP? Quer ajuda para dar conta do seu backlog? Nós podemos ajudá-lo a superar esses desafios. Para isso, fale com nossos consultores.
