Falhas comuns no refinamento de Product Backlog

Dentre as tarefas principais do papel de Product Owner, dentro do Scrum, está o refinamento do product backlog. O Product Backlog, ou Backlog de Produto, é o artefato ágil para gerenciar os requisitos de um determinado produto. Este artefato é de domínio exclusivo do Product Owner, que refina-o constantemente para que os itens mantenham-se priorizados (usando diversas técnicas), detalhados e que façam sentido com a estratégia de mercado em cima deste produto.

Falo mais disso no rápido vídeo abaixo:

Imagine que quando um novo produto está sendo criado temos uma vaga ideia do que queremos que ele se torne. Dentre tudo o que gostaríamos de ter no produto (o roadmap), o Product Owner deve priorizar o que é mais urgente, trará maior valor aos clientes ou trará o ROI mais rapidamente. Estes itens mais prioritários são então detalhados (em User Stories, por exemplo) para que sejam entregues ao time de desenvolvimento trabalhar durante a próxima iteração. Enquanto o time trabalha no desenvolvimento destes itens (o Sprint Backlog), o P.O. trabalha no refinamento dos itens da sprint seguinte, para que tenhamos itens priorizados e detalhados para a Sprint Planning seguinte.

Parte desse processo de refinamento, limitado em até 10% da capacidade de trabalho do time de desenvolvimento, pode ser compartilhado com o time de desenvolvimento, em sessões de Product Backlog Refinement, também chamadas de Grooming Sessions. Nestas sessões, o Product Owner faz uma prévia do que ele planeja para a Sprint Planning seguinte, o time já faz questionamentos, já agenda spikes e/ou POCs e já dá um overview de riscos e preocupações que eles possuem em cima do que está sendo planejado.

Futuramente, usa-se o feedback recebido nas Sprint Reviews e do próprio mercado (quando as primeiras versões do produto estão em produção) para ajudar neste processo de refinamento, criando um ciclo virtuoso de melhoria contínua.

Até aí tudo bem, mas o que pode dar errado no processo de refinamento do Product Backlog?

Muitas coisas!

Priorização e refinamento externo

Quem prioriza o Product Backlog é o PO. Ponto. Qualquer outra opinião ou feedback externo é bem vindo, mas a decisão final das prioridades de requisitos a serem entregues pro time de desenvolver é do PO. Obviamente que o mesmo deve estar alinhado com a estratégia da empresa para não criar um produto que não ajude a organização a atingir a sua visão, mas jamais o PO deve ser alguém que “apenas” repassa as prioridades da empresa para o time de desenvolvimento. Tire esse poder do Product Owner e teremos um Waterfall 2.0.

Outra falha é muitas vezes o P.O. copiar-e-colar os itens de backlog de algum documento dos stakeholders. A construção do product backlog é um trabalho criativo, iterativo e incremental. Não é uma conversão de um modelo tradicional para um modelo ágil para que o time se sinta melhor dizendo que trabalha ágil.

Product Backlog Completo

Jamais o P.O. deve querer refinar completamente o Product Backlog de uma vez só, no início do projeto. Se o seu escopo é fechado e o seu produto final já está delimitado, qual o sentido de rodar Scrum ou qualquer outro método ágil? Qual a chance de você estar certo hoje sobre as features que serão necessárias no seu produto daqui a 6 meses? Onde entra a inovação neste processo?

O refinamento do Product Backlog deve ser iterativo e incremental, assim como o Scrum e o Lean Startup pregam. Mantenha um estoque de itens priorizados e detalhados para até um mês à frente, no máximo. Mais do que isso e a chance de você jogar muito trabalho fora é enorme.

Isso é uma verdade ainda maior no que tange estimativas de tempo de projeto. Jamais deixe que o time de desenvolvimento estime mais do que uma sprint e meia. A chance de estimativas “perderem a validade” nestes casos é muito grande em virtude de mudanças de arquitetura, dependências, prioridades, etc é muito grande e com isso perdemos o tempo que se levou estimando.

Parking Lot misturado com backlog

Features que não são debatidas, priorizadas ou detalhadas há mais de um mês devem sair do Product Backlog para não atrapalhar refinamentos posteriores. A sugestão é criar um backlog separado, chamado de Parking Lot ou Icebox. Abordagens mais drásticas como a do Getting Real dizem que estas features deveriam simplesmente ser excluídas. Se elas realmente forem importantes, voltarão a aparecer.

Histórias incompletas

As histórias devem sempre buscar entregar valor ao usuário final, de uma ponta a outra, o chamado “fatiamento vertical de features”. Histórias que entregam cenários pela metade, os famosos componentes (fatiamento horizontal), devem ser evitadas ao máximo pois causam um acúmulo de itens com pendências que não podem subir para produção.

Só geramos valor com o produto quando o usuário passa a gerar valor com ele (ou a empresa, enfim). Até então, temos investimento ou desperdício, mas nunca geração de valor.

Além disso, um item do product backlog somente deveria ser dado como refinado quando os seus critérios de aceitação estão claros. Apenas escrever a história (ou pior ainda, apenas ter um título) não é o bastante. Um artefato que ajuda o Product Owner a ter certeza que sua história está pronta para entrar na próxima sprint é a Definição de Preparado (Definition of Ready).

Basicamente uma Definição de Preparado é um checklist (assim como a Definição de Pronto) que deve ser repassado para garantir que cada história realmente está ‘preparada’ para entrar em desenvolvimento. Obviamente isto pode variar de time para time mas coisas como critérios de aceite, o modelo a ser seguido de user story, um screenshot da UI desenhada, etc são coisas que você pode ter. Nenhuma história deveria ser discutida em uma Sprint Planning sem antes ter sido preparada em groomings.

Histórias ‘completas’ demais

O papel do P.O. é definir para ‘quem’ criamos ‘algo’ e ‘porquê’, mas jamais ‘como’ o time deve fazer isso. A multidisciplinaridade de um time de desenvolvimento deve garantir, por exemplo, que tenhamos profissionais de UX para criar as melhores experiências e interfaces gráficas, que tenhamos profissionais de QA para garantir a qualidade da entrega, profissionais de sistemas para garantir a melhor técnica de programação e assim por diante. Deve haver confiança de que cada pessoa é capaz de executar a sua atribuição da melhor maneira possível e que a soma de todos é que constrói o melhor produto, e não o ego de uma pessoa apenas.

Se o PO define como os programadores devem escrever o código, como os designers devem criar as telas e como os testers devem testá-las, porque temos um time? Não é mais fácil terceirizar tudo pela Internet? E qual a chance dele ser bom de fato em todas estas skills, além da skill de negócio que é a mandatória do papel?

Detalhe as histórias até o ponto que o time de desenvolvimento tenha as informações necessárias para aplicar as suas skills da melhor forma que eles entenderem, sem jamais restringir a sua capacidade criativa e intelectual impondo requisitos técnicos demais que fogem ao escopo de negócio. Mesmo no âmbito de negócio, o P.O. deveria consultar os stakeholders para garantir sempre o alto alinhamento com a empresa.

Itens de backlog soltos

Todo item de backlog deve fazer parte de uma hierarquia que faça sentido dentro da estratégia do produto, para que seja possível entender porque ele é importante ou onde ele se encaixa.

Itens de backlog soltos geram software desenvolvido que não se encaixa em lugar nenhum, telas que não “conversam” com as demais telas do sistema, regras de negócio e de experiência que não são uniformes, etc. Quer você opte por apenas dois níveis (épicos e histórias) ou mais níveis (no TFS temos épicos, features, histórias e tarefas, por exemplo), é importante que cada história faça parte de algo maior.

A composição total dos épicos é o que chamamos de roadmap e o ideal é que ele seja público (transparente) e que não seja mais longo do que 3 meses para produtos inovadores e complexos. Além disso, ele deve ser minimamente possível de se realizar dentro do time-to-market pelo time existente, mesmo sem um estudo detalhado e estimativas minunciosas.

Achismos

Ok, o Product Owner tem a palavra final sobre o Product Backlog, mas ele sempre deve ter argumentos para explicar a sua priorização e detalhamento. Itens obscuros devem ser estudados, itens complexos devem ter spikes e POCs, itens que dividem opiniões devem ter dados de mercado e assim por diante.

Forçar sua opinião para definir uma história sem argumento é o primeiro passo para quebrar a confiança com seu time ou pior ainda, quebrar a cara com seu produto.

Uma técnica que pode ajudar a mostrar se uma história está no campo do “achismo” ou não é usar o gráfico de entendimento técnico e de negócio para nivelar a user story, oriundo do Lean Inception. Se a história cair nos quadrantes com X, ela não deveria ser levada pra Planning, pois não há clareza suficiente.

P.O. Part-Time

A função de Product Owner é uma demanda de tempo integral que não se ajusta bem a mais responsabilidades. Refinar o product backlog apenas uma vez por semana antes da próxima Sprint Planning não é o bastante, esse refinamento deve ser diário, de acordo com a evolução do projeto nas mãos do time.

O PO deve ter tempo para estar sempre atendo aos acrônimos DEEP e INVEST.

Time submisso

O time deve contribuir com o product backlog durante o refinamento e principalmente durante a Planning. Um time submisso que apenas executa o que o Product Owner decide acaba se metendo em confusão rapidamente.

Dificilmente o Product Owner irá se atentar ou mesmo priorizar débito técnico. Cabe ao time levantar esta bandeira quando necessário. Poucos P.O.s tem capacidade, principalmente em início de projeto, de entender se um time está se sobrecarregando ou não em uma Sprint Planning, o próprio time tem de ter esse discernimento e dizer ‘chega’ quando acreditarem que já se comprometeram com itens suficientes para a sprint. E os incidentes? Se o produto já está em produção, podem acontecer incidentes e é importante o time manter o P.O. a par do volume de chamados que costumam entrar ao longo do período da sprint.

Estes são alguns problemas que costumo perceber auxiliando Product Owners e até mesmo atuando nesta função em diversas ocasiões. Concorda? Discorda? Tem algum ponto a acrescentar? Deixe nos comentários!

Caso queira conhecer duas excelentes ferramentas para gestão de backlog, dê uma olhada nos vídeos abaixo onde ensino a usar o Jira e o Azure DevOps.