Como você cuida do seu Tamagotchi chamado “Product Backlog”?
“Gerenciar o backlog é uma arte, ou você tem o domínio e controle dele, sendo o verdadeiro guardião, ou você perde o rumo do produto.”
Uma das perguntas que mais ouço em cursos de produto, meetups e nas rodas de networking de Product Owner (PO) e de Product Manager (PM) é “Como você criou e mantém seu product backlog?”. Isso, me fez criar o primeiro artigo sobre o tema — Como criar um Product Backlog?
Mesmo assim, senti falta de entender um pouco mais sobre como PO/PM utilizavam-se das ferramentas para a construção do Product Backlog, então resolvi criar um questionário com 15 perguntas acerca do tema. No total, 62 profissionais responderam a pesquisa e neste artigo compartilho com vocês os resultados.
Mas antes disso, você se lembra do Tamagotchi? Se você nasceu na década de 90 com certeza sabe o que é e inclusive deve ter tido vários, mas se você nasceu nos anos 2000 ficou curioso para saber. O Tamagotchi era bichinho virtual que era febre nos anos 90. O brinquedo tinha um formato redondinho e uma tela pixelada, e o dono precisava manter um animalzinho virtual vivo com constante cuidado e atenção.
Mas o que tem haver o Tamagotchi e o Product Backlog?
Essa analogia serve para nos lembrar que o Product Backlog é um “serzinho” que precisa de cuidado e atenção constantes. Afinal, para se ter um produto que atenda as necessidades das pessoas é preciso que ele agregue valor durante o seu uso.
É muito comum ouvir e até vivenciar backlogs cheios de estórias de usuária que foram criadas há meses e que estão esperando para serem desenvolvidas e que já perderam o time-to-market.
Um dos papéis da pessoa PO/PM é justamente analisar aquilo que faz sentido para o produto naquele momento, tendo em vista a estratégia da empresa, o mercado e seus concorrentes e priorizar de forma a entregar o máximo de valor em menor tempo. E para que isso aconteça o Product backlog é vivo e está em constante construção e desconstrução.
A pesquisa
A primeira pergunta foi: Como você iniciou o Backlog do produto que atua? Nota-se que a resposta “Entrevistas “face to face” com clientes” é utilizada por 28,5% de POs/PMs, seguidas de Design Sprint e Matriz CSD (Certezas, Suposições e Dúvidas), 16,9% e 13,8% respectivamente e bem perto fica o Lean Inception/Lean Canvas com 13,1%.
A segunda pergunta questiona sobre como é retroalimentado o Product Backlog? Nesse caso, o que obtivemos resultados mais expressivos foram: Brainstorming de Funcionalidades (26,9%). Feedbacks captados como resultado das primeiras entregas (26,3%) e Entrevistas “face to face” com clientes (20,6%).
A terceira pergunta questionou: “Em qual formato você escreve/escreveu os Product Backlog Items (PBI)?”
Afinal, os PBIs é o nome correto, uma vez que dentro do Product Backlog, temos requisitos não funcionais, bug, débitos técnicos e estórias de usuárias (na minha visão por ter mais estórias de usuárias as pessoas acabam utilizando esse termo e não PBIs).
A grande maioria das respostas 79% utiliza o modelo de estórias de usuária.
Questionado sobre “Você faz o refinamento dos PBIs?”. Que está ligado diretamente na avaliação do time-to-market das funcionalidades e no detalhamento técnico pelo time de desenvolvimento de como fazer, 14,5% disseram que não fazem.
A próxima pergunta abordou “Como você faz o Refinamento dos PBIs do Product Backlog?” e a que obtivemos maior expressão de respostas foi: Momento de Refinamento com o time/Grooming (46,8%).
Uma polêmica também que cerca as rodas de conversa é o tamanho do Product Backlog. Claro, que a quantidade de PBIs, é influenciada pelo tamanho do time, complexidade do produto e outros fatores. Então o que pode ser extenso para um produto, pode ser pequeno para outro. A pergunta foi: Qual o tamanho do seu Product Backlog? Mais da metade dos respondentes disseram que é de 1 a 50 estórias de usuária (51,6%).
Em seguida questionamentos se o PO/PM acredita que seu Product Backlog está extenso? E nota-se que não há uma ideia fechada sobre o tamanho, justamente pelos fatores citados acima.
Em complemento dessa questão, os que marcaram sim, pedimos que informasse o motivo que acredita estar ocasionando o product backlog extenso.
Dentre as respostas temos:
- “Há muitas histórias lançadas mas algumas não estão conectadas com a visão de produto a longo prazo.”
- “Há algumas coisas que foram despriorizadas e foram entrando muitas outras com maior urgência, só que a lista começou a ficar infinita.”
- “Heranças de Product Backlog de POs/PMs anteriores.”
- “Porque as pessoas não sabem o que tem no backlog, e o backlog são apenas títulos, não existe nenhum resumo do problema a ser resolvido.”
- “Muita demanda de clientes e pouco braço para fazer.”
- “O produto é bem grande.”
- “Muitas áreas com necessidades diferentes e portanto entregar valor ao negócio.”
- “Por que fizeram um planejamento tradicional anterior.”
- “Muitos débitos técnicos.”
- “Por que vamos inserindo coisas novas e não fazendo a que já estão criadas.”
Talvez, você tenha percebido seu problema nessas respostas, não é mesmo?
“Gerenciar o backlog é uma arte, ou você tem o domínio e controle dele, sendo a verdadeira guardiã, ou você perde o rumo do produto.”
Questionado sobre“ Como você documenta o Product Backlog?” E a ferramenta Jira foi a mais citada com 54,8%.
Também questionamos sobre: “Você analisa o time-to-market dos PBIs que você criou?” E a maioria das respostas, foram “Às vezes, só quando a funcionalidade é muito importante” com 48,4%.
E para encerrar essa pesquisa perguntamos “ O que você faria diferente para manter seu Product Backlog atualizado?”
E as respostas que apareceram com maior frequência foram:
- Conversar com stakeholders frequentemente para entender se a demanda e seu valor para o negócio. Que eu diria que trata-se de um refinamento de negócio.
- Ter mais reuniões de refinamento com time de desenvolvimento.
- Melhorar a gestão de tempo, para realizar a revisão do Product Backlog em uma determinada hora do dia sem interrupções.
- Trabalhar com épicos.
Considerações Finais
Para finalizar esse artigo, que já ficou extenso demais (risos), posso dizer que aprendi muito com cada pessoa que respondeu e expôs suas dores e angústias. Uma das inferências que podemos fazer, é que não há certo ou errado, mas sim vários modos de fazer a mesma coisa. Para algumas pode ser mais fácil e para outras mais complexo. O que importa no fim do dia para POs/PMs é se questionar : “Eu entreguei valor para as pessoas?” ou “eu resolvi uma dor ou problema?” ou no meu atual mundo de games “eu consegui entreter as pessoas que jogaram a ponto delas ter uma conexão emocional e colocar o jogo como um hábito em sua rotina?”
Espero ter contribuído com a comunidade e em breve compartilho os resultados dessas questões na perspectiva da Sprint Backlog.
Publicado originalmente em: http://mirellynogueira.com.br
