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.

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

P.O. Parcial

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.

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!

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Criando um roadmap de produto de maneira ágil

Quando estamos iniciando um novo produto ou até mesmo evoluindo um produto já existente é muito importante um mínimo de organização para que saibamos onde queremos chegar, o que queremos ter no produto, etc. Mesmo em casos onde a mudança seja constante, ter um roadmap ajuda a tomar decisões de escopo, de priorização e principalmente, de ter uma ideia do quão longe estamos de chegar aonde queremos.

Existem diversas técnicas para criação de roadmaps de produtos. Dentre as técnicas mais ágeis e que não tentam ser lá muito precisas, até porque tentar prever o futuro é algo bem impreciso na minha opinião, temos a Futurespective e a Matriz Valor x Risco. E é delas que falarei hoje, embora outra dinâmica complementar seja a Buy a Feature Game que já falei antes.

Matriz Valor x Risco

A matriz de valor x risco é um artefato ágil para dimensionar o tamanho de um projeto ou roadmap, além de ajudar na priorização do mesmo e definição dos épicos e features de um produto.

Você pode fazer esta dinâmica com folhas A3, quadros brancos ou ainda flip-charts. Ela não é uma dinâmica muito boa de aplicar em times grandes, o ideal é que não passe de 5 pessoas e, por se tratar de uma dinâmica focada no negócio, o ideal é não ter a presença de membros que não possuam (ou não gostem) a visão de negócio do produto.

Desenhe uma matriz bi-dimensional com dois eixos, tipo um plano cartesiano. No eixo vertical, escreva Valor e no eixo horizontal, escreva Risco. Cada eixo deve ter duas ou mais partes, como Baixo, Médio e Alto Valor, ou Baixo, Médio e Alto Risco, de baixo para cima e da esquerda pra direita, respectivamente. Se você procurar na Internet vai ver variações, como na imagem abaixo, que ajudam a entender como a sua matriz pode ser organizada.

Matriz Valor x Complexidade
Matriz Valor x Complexidade

Em post its escreva as features ou épicos do seu produto e posicione um-a-um os posts its nos quadrantes apropriados, considerando o quanto valor eles irão agregar para os clientes e/ou para a empresa e o quanto de risco eles possuem.

Considere Valor como não sendo algo meramente financeiro. Valor pode ser engajamento, pode ser marketing boca-a-boca, pode ser algo que gere mais NPS, pode ser algo que reduza o churn, que aumente a conversão, etc. Embora tudo isso de uma forma ou de outra se traduza em dinheiro, não precisa se apegar a valores financeiros diretos. Essa definição mais abrangente de valor é algo a ser levada a sério, pois até mesmo aparece na prova da certificação de PSPO.

Considere Risco como qualquer coisa que torne mais arriscado pegar esta feature ou épico para implementar. Pode ser muito esforço necessário, muito custo, desconhecimento dos detalhes, falta de tecnologia ou de pessoal especializado para tocar a tarefa. Pode ser um prazo muito justo ou uma complexidade muito alta de desenvolvimento. Tudo isso representam riscos para que tenhamos sucesso na empreitada deste épico.

Após terminar de colocar os post its nos lugares certos cabe ao time decidir a sua estratégia de priorização do roadmap. Não há uma única estratégia válida aqui  pois cada empresa tem a sua realidade, mas uma análise importante dos quadrantes incluem:

  • alto valor e alto risco (topo á direita): geralmente o que possui alto risco e alto valor são as que realmente darão um retorno altíssimo para a empresa. O fator risco deve ser mitigado o mais rápido possível para que não sejamos surpreendidos no futuro por algo que acabe minando o projeto como um todo. Atacar o alto risco/alto valor primeiro é uma estratégia segura a longo prazo;
  • alto valor e baixo risco (topo á esquerda): uma estratégia de curto prazo, boa quando se está com a corda no pescoço e precisam-se de ações rápidas e que gerem valor. Em outras situações, ataque estas após as alto risco/alto valor.
  • baixo valor e baixo risco (embaixo à esquerda): não é uma boa estratégia, geralmente só devem ser priorizadas em casos de ociosidade ou em períodos “entressafras”;
  • baixo valor e alto risco (embaixo à direita): jamais faça elas, não valem a pena.

Ao definir sua regra de priorização, você terá o seu roadmap definido e priorizado. Se precisar de alguma estimativa de alto nível, convém jogar um Planning Poker sobre o menor épico que valha a pena desenvolver (alto valor e baixo risco?) e, após estimá-lo, projetá-lo sobre os demais post its para ter uma ideia total do roadmap.

Por exemplo, se o menor épico ganhar um 3 e você decidir que ele demora em média 2 meses, some os demais pontos e divida por 3 para saber o número de meses do seu roadmap. Mantenha uma escala exponencial como a de Fibonacci para pontuar tarefas baseadas em seu risco, para não cometer o erro de estimar um roadmap muito “no detalhe”.

Futurespective

Essa dinâmica pode ser complementar à Matrix Valor x Risco ou mesmo substitui-la. Sua abordagem é ainda menos precisa e muito mais ágil, quando estamos em uma de duas situações:

  1. você quer ver se o seu time está alinhado com a visão estratégica da empresa em relação ao(s) produto(s) que estão desenvolvendo;
  2. você quer construir um roadmap do produto de maneira colaborativa, com o seu time, para dar uma visão comum a todos;

Seja qual for o seu objetivo, esta dinâmica é bem interessante e pode render bons frutos, apenas não se preocupe em gerar um plano de ação detalhado com ela, pois isso não irá acontecer. Conheci ela durante um workshop do Daniel Wildt e achei bacana reproduzir aqui.

Separe o seu time em grupos de até 3-5 integrantes. Evite grupos muito grandes para evitar discussões desnecessárias. Essa não é uma dinâmica que trará precisão no seu roadmap, mas um alinhamento geral muito bom, então não tem necessidade de discutir nos mínimos detalhes os prazos e prioridades das coisas.

Estabeleça que cada participante vai escrever 10 post-its com épicos ou features que ele acredite ser importante para o produto e que ainda não foram desenvolvidas.

Após todos escreverem,  cada membro deve apresentar aos demais o que ele escreveu. Juntos, devem definir quais x itens devem ser prioridade para os próximos 3 meses (desconsiderando repetidos), sendo que x deve ser o número de integrantes da equipe que está fazendo a dinâmica. Depois, quais os próximos x que devem ser prioridade para os 3 meses posteriores e assim por diante, até os itens terminarem.

Para tomarem a decisão de prioridade, pode ser usada a Matriz Valor x Risco, a Buy a Feature Game ou qualquer outra dinâmica que você conheça. O resultado dessa dinâmica será um roadmap de alto nível que garante uma visão comum entre os membros do time.

Eventualmente este roadmap irá ser alterado, mas não tem problema, como diz no Manifesto Ágil: mais vale responder às mudanças do que seguir um plano.

Quer saber mais sobre desenvolvimento ágil de software? Clique no banner abaixo e conheça o meu livro.

Agilidade em escala corporativa – Parte 2

No post passado sobre agilidade em escala corporativa mencionei o famoso modelo do Spotify, também chamado de “Scaling Agile @ Spotify” ou simplesmente “modelo em squads”. Falei sobre os squads, os chapters, as tribes e as guilds. Isso tudo é o que a teoria de 2012 do Spotify nos diz sobre agilidade em escala corporativa e um possível passo número um para grandes corporações inovarem nos seus métodos ágeis para que os mesmos se adequem à realidade de dezenas de times operando Scrum ao mesmo tempo.

Mas será que de 2012 pra cá nada mudou em termos de agilidade para grandes empresas? Será que o próprio Spotify ainda organiza-se da exata maneira em que é citado no famoso vídeo?

Melhoria Contínua

Os três pilares do Scrum são bem claros: transparência, inspeção e adaptação. Estes dois últimos tratam exclusivamente de melhoria contínua. Qualquer time ágil que se preze deve continuamente revisitar seus processos para aprimorá-los e por isso não há como acreditar que há 5 anos o Spotify descobriu o Santo Graal dos métodos ágeis e jamais teve de modificá-lo. E de fato, isso não aconteceu, embora poucas pessoas falem disso.

Segundo Andy Park, um ex-Agile Coach do Spotify, entre 2012 e 2014 o modelo sofreu algumas mudanças que fazem todo sentido para mim, considerando desafios como os que enfrento em aplicar agilidade em escala corporativa no Banco Agiplan.

A primeira mudança é sobre a liderança das tribos. As tribos, para quem não se lembra, são a junção de diversas squads que possuam uma área de negócios/projetos em comum, no caso de um banco, temos a tribo de crédito, a tribo de canais, a tribo de integrações, etc. No modelo original, toda tribo deveria possuir um tribe leader, que responde pelo alinhamento e suporte às squads sob sua responsabilidade. No entanto, este modelo original de um tribe leader nos leva a um impasse em diversos casos: o líder deve ser alguém da área de negócios ou da área de tecnologia?

Algumas tribos são mais de tecnologia e outras mais de negócios. No entanto, dificilmente eles não dependem fortemente de ambas as áreas. Não obstante, muitas vezes o número de squads dentro de uma tribo é proibitivo para apenas um líder consiga exercer seu papel de facilitador com qualidade. E embora sempre possamos argumentar que podemos dividir uma tribo em duas, na prática isso acaba gerando problemas de alinhamento e é algo que queremos evitar.

Mas e se tivéssemos ao invés de um, mais de um tribe leader? Que tal dois, como um líder de negócios e outro de TI, por tribo. Desta forma, garantiríamos que ambas skills garantissem que as squads tenham todo o suporte e alinhamento necessários para seus POs e devs. Claro, dois é uma sugestão, e nem sempre ter mais de um será algo necessário. O que ficou claro é que o Spotify agora não restringe a liderança da tribo a apenas uma pessoa. Isso vai depender da necessidade individual de cada tribo.

Tribo com liderança dividida
Tribo com liderança dividida

A segunda mudança é sobre o alinhamento entre tribos. Uma coisa é implantar o modelo de squads em uma empresa como a Umbler que possui dezenas de funcionários e nem mesmo possui tribos (a startup inteira é apenas uma tribo com diversos produtos, um por squad). Outra coisa é manter o alinhamento entre diversas tribos em uma empresa com dezenas de funcionários apenas no setor de TI, fora a área de negócios que não faço nem ideia do tamanho que é.

Quando se tem várias tribos, é muito comum que deva existir um alinhamento estratégico entre os líderes de tribos, para que os mesmos consigam alinhar as suas squads. Quando temos poucas tribos, isso é simples de fazer, mas conforme a coisa cresce, a preocupação com o alinhamento se torna maior pois ele se torna ainda mais crítico. Para piorar, algumas tribos dependem fortemente de outras, criando um ponto crítico para que o todo funcione.

Entre essas tribos que dependem fortemente umas das outras, recomenda-se atualmente a criação de Alliances (alianças), que são o modelo ágil das superintendências de grandes corporações. Da mesma forma, as Alliances possuem seus líderes, que são responsáveis por manter os líderes das tribos da aliança alinhados, ao mesmo tempo que lhes fornecem os recursos necessários para que suas tribos prosperem, como orçamento, estratégias, etc.

Alianças
Alianças

Algumas tribos não precisam participar de alianças, não é exatamente uma questão de hierarquia. Havendo a necessidade (temporária ou não) de duas ou mais tribos terem um altíssimo alinhamento entre elas, forma-se a aliança e designa-se um ou mais líderes para a mesma.

Voltando às Origens da Agilidade

Você leu bastante a palavra alinhamento neste artigo, certo? Isso porque um alto alinhamento é a chave para termos times autônomos. E times autônomos são a chave para termos agilidade. Mas como obter um alto alinhamento sem o demônio do microgerenciamento invadir nossas empresas?

Uma das possíveis respostas para esta pergunta vem das origens da agilidade: a manufatura industrial japonesa, mais especificamente do famoso chão de fábrica da Toyota Motor Company onde surgiu o processo Lean que inspirou tantas metodologias ágeis incluindo o Scrum, o Lean Canvas (do Ash Mauryia) e o Lean Startup. Dentre tantos aspectos e literaturas a respeito do Toyota Lean, gostaria de destacar um método muito interessante que só fui descobrir recentemente que é o Toyota Kata, mais especificamente o Improvement Kata ou Kata de Melhoria na tradução.

Não quero me estender aqui sobre o Improvement Kata, até porque ainda é um estudo em andamento que estou fazendo e pretendo escrever sobre ele no futuro, mas gostaria de ressaltar o seu funcionamento básico como um incrível método para garantir o alinhamento estratégico e a melhoria contínua dentro das organizações, em especial as grandes, onde problemas de alinhamento são mais comuns.

Basicamente um kata, assim como nas artes marciais japonesas, é a repetição de um método até que ele se torne instintivo. Todo mundo já deve ter visto Karatê Kid, certo? Tanto o antigo do sr. Myagi quanto o mais recente com o Jackie Chan, ambos mostram o que é um kata de maneira bem simplificada com os exercícios repetitivos e monótonos que os meninos realizam para só então, quando a hora chegar, aquilo tudo virar instinto. O Improvement Kata em questão, é um processo repetitivo que apesar de manter o foco e alinhamento no que foi definido como a estratégia da empresa, não restringe a liberdade de execução dos projetos.

Não quero me estender demais para não estragar o conteúdo que estou estudando e deixando para um post exclusivo sobre o assunto. Basta dizer que o Kata é a cola que faltava para sincronizar as tribos, alianças, etc dentro de uma grande organização.