Grooming Canvas – Todas as user stories estão no inferno!

Dentro do paradigma ágil, quando estamos num processo de desenvolvimento de um produto,  buscamos iniciar todos os nossos esforços de entendimento e até mesmo de desenvolvimento por aquilo que acreditamos que será o maior valor do produto.

O  próprio Scrum estimula que um Product Owner (vulgo PO) comece a “povoar“ seu Product Backlog aplicando um forte senso de priorização baseada em valor. E de maneira geral, muitas organizações tem uma enorme dificuldade em definir  ou consensualizar o que é valor. Mas isso é assunto para outro texto.

Contudo, ao longo do tempo, comecei a notar uma tendência forte entre os POs e times de produtos. Podemos nomear essa tendência com a famosa frase de “no final, tudo é importante!”

Isso acontece pois seria uma ingenuidade achar que conseguiríamos, de imediato, já iniciar o nosso pensamento sobre o produto pelo mais importante e excluir as funcionalidades que não agregam valor. Na verdade isso é bastante perigoso. O perigo se dá pois, na tentativa de começar um Product Backlog pelo seu topo de prioridade, ordem e valor, acabamos gerando o mesmo problema de excesso de funcionalidades nos produtos desenvolvidos. Na prática, muitos Product Backlogs tem um topo muito extenso.  E é aí que mora o perigo.

Ao meu ver, isso acontece pois muitos praticantes de agile se distanciaram de um item muito importante do manifesto ágil. Na verdade, o item em questão é um dos doze princípios ágeis (pois é, eles existem! Usa Agile e não sabia disso? Shame on you!). Mas especificamente,  estou me referenciando ao décimo princípio.

O Décimo princípio do Manifesto Ágil diz:  Simplicidade – A arte de maximizar a quantidade de trabalho não realizado – é essencial.  Esse princípio, na minha opinião, é matador!  Na prática ele  toca na ferida ou na maior dificuldade na adoção do pensamento ágil na criação de produtos. Essa dificuldade se dá pelo fato de que Agile preconiza o desapego de (muitas) partes desejadas para um determinado produto.   Quando se contrasta “coisas que tem valor” versos “coisas que não tem tanto valor”,  o exercício  de priorizar e descartar fica fácil. Mas quando se contrasta “coisas que tem valor” versos “coisas que também tem valor”, aí o desafio começa.

Meu amigo Rodrigo de Toledo menciona:  “Nos tempos atuais, o trabalho do profissional de informática deveria passar a se concentrar na SÍNTESE de sistemas. Devemos remover funcionalidades ao invés de gerar mais.” Sendo assim, um dos maiores desafios econômicos e culturais do desenvolvimento de software é criar e efetivar uma inteligência saudável de descartar o máximo possível de trabalho não feito, para poder focar na menor parte de maior valor do produto.

Para ajudar a resolver esse problema (veja bem, ajudar, não resolver, ok?) há algum tempo sugiro para os POs o seguinte exercício:  Vamos adotar a premissa de que “Todas as user stories têm baixo valor até que se prove o contrário!”. A ideia é transformar esse pensamento numa espécie de mantra ou numa regra que deve ser seguida a risca a cada item desejado para o Product Backlog.

Ao seguir essa regra, O PO precisa fazer um difícil exercício. Esse exercício é difícil pois como todos os itens já nascem com baixa prioridade, o PO, tem se esforçar em fazer aquele item merecer ir para o topo do Product Backlog.

É  importante alertar que o elemento que mostrarei em seguida, não oferece uma maneira explícita para identificar a priorização.  Cabe a cada PO identificar uma forma ou técnica para fazer essa priorização. O importante que essa priorização aconteça por critérios transparentes e passíveis de discussão dentro da organização.

Para apoiar esse exercício, criei uma espécie de canvas (ver figura abaixo) para guiar, de maneira visual, esse raciocínio.  A esse canvas chamo carinhosamente de Grooming Canvas, pois  sua aplicação serve exatamente para ajudarmos o processo de grooming (refinamento e organização) dos itens de um Product Backlog.  Essa prática de grooming, no fundo, tem um caráter contínuo no desafio em tornar os itens mais prioritários em estágio de DOR (Definition Of Ready).

Nesse canvas,  temos 2 eixos. No eixo vertical, temos a dimensão de valor seguindo a premissa de priorização que explicamos acima. E no eixo horizontal, temos a dimensão de tamanho. A dimensão de tamanho segue o mantra de “Todas as user stories são um ÉPICO/TEMA até que se prove o contrário!”. O tamanho é outro ingrediente importante nessa conversa.  Pois se algum item tem pouco valor de negócio, não precisamos investir (ou gastar) tempo em detalha-lo. A ideia do Épico ou Tema é uma forma de identificarmos e mostrarmos o quanto um item ainda está muito grande, ou há muita incerteza, ou ainda não está num tamanho suficiente pequeno para entrar em uma Sprint.  Dessa forma, por ser um TEMA/ÉPICO isso significa que aquele item precisa ser quebrado/desmembrado em itens menores e factíveis de entendimento, por exemplo.

Juntando as regras de que todas as user stories são grandes e também têm baixo valor, notamos que por padrão, os itens do backlog já nascem no final do mesmo (representado pelo canto inferior direito do canvas). E cada vez que vamos refinando e entendo mais sobre o seu contexto de negócio, o  item vai subindo ao topo do backlog (que no canvas é representado pelo canto superior esquerdo).

Uma maneira de compreender a dinâmica e os fenômenos que ocorrerão no canvas, é usando a metáfora Dantesca para classificar as coisas. Nessa visão (ver figura abaixo), é possível resumir que todo e qualquer item, já nasce no inferno (cruel, não?) e ele precisa ser trabalhado em termos de prioridade e redução de tamanho para poder merecer entrar no céu.

Esse canvas acaba sintetizando uma forma um pouco contra-intuitiva para priorizar e refinar itens de um Product Owner.  Pelo fato de ser contra-intuitivo, demanda um esforço maior por parte de um PO. Lembro-me que na primeira vez que usei essa abordagem era possível ouvir (metaforicamente) os estalos das sinapses na cabeça do pobre PO.

Infelizmente apliquei e acompanhei esse canvas em poucos projetos reais. Mas mostro-a de maneira frequente aos alunos do curso de Requisitos Ágeis aqui na Adaptworks.  E durante ou após o treinamento, sempre recebemos feedbacks muito positivos quanto à mesma. Dessa forma, o objetivo desse texto foi socializar essa simples abordagem.  Desejo que outras pessoas sintam-se estimuladas a experimentarem e nos falarem dos resultados/dificuldades encontradas em sua aplicação. Maiores dúvidas ou sugestões, sintam-se convidados a me contatar em [email protected] ou pelo meu twitter: http://twitter.com/manoelp .  Até lá!