Como você cuida do seu Tamagotchi chamado “Product Backlog”?

posted in: Viagem | 0

“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 os 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 dos clientes/usuários é preciso que nossa lista de funcionalidades esteja aderente ao que os clientes entendam e percebam como valor naquele momento e não no que queriam há dias ou meses atrás.

É muito comum ouvir e até vivenciar backlogs cheios de estórias de usuário 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 do 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% dos 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%.

OBS: A resposta permitia mais de uma opção de escolha

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%).

OBS: A resposta permitia mais de uma opção de escolha

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ários ( na minha visão por ter mais estórias de usuários as pessoas acabam utilizando esse termo e não PBIs).

OBS: A resposta permitia mais de uma opção de escolha

A grande maioria das respostas 79% utiliza o modelo de estórias de usuário.

http://mirellynogueira.com.br/wp-content/uploads/2019/05/Est%C3%B3ria.png

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ário (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 conectada 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?

Eu digo que 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.

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 os 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 um 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 uns pode ser mais fácil e para outros mais complexos. O que importa no fim do dia para um PO/PM é se questionar “eu entreguei valor para o meu cliente?”, “eu resolvi uma dor ou problema dele?” ou no meu atual mundo de games “eu consegui entreter o jogador a ponto dele 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.

Leave a Reply

Your email address will not be published. Required fields are marked *