Em muitos casos, quando estamos em clientes, nos deparamos com uma situação que pode gerar um certo desconforto em alguns Product Owners e até mesmo em algumas pessoas com foco no processo como Scrum Masters, Agile Coaches ou Gerentes de Projetos. É que uma user story grande corre o risco de demorar a “gerar valor”, por ficar dias e mais dias no ciclo de desenvolvimento. Nesse momento, surge a grande dúvida: devemos quebrar essa user story? Essa pergunta vem com uma série de outros questionamentos, como por exemplo: “A user story quebrada vai gerar valor?”, “a user story quebrada vai ser perceptível pelo cliente?”, “como vamos explicar um aumento de backlog aos sponsors do projeto?”. Essas perguntas influenciam a decisão, deixando-a mais difícil de ser tomada, e com um peso grande sobre o colo do Product Owner, e de quem o estiver auxiliando no processo.

Muitas dessas dúvidas talvez surjam por conta dos conceitos que temos desde o “lançamento” do ágil. O conceito de “história do usuário”, algo que deve ser escrito pelo usuário, indicando na visão dele, uma necessidade para o produto ou projeto. Segundo o que Mike Cohn argumenta, uma user story deve ser pequena, com descrição simples de uma funcionalidade contada a partir da perspectiva da pessoa que solicitou, geralmente um usuário ou cliente do sistema. Por conta disso, nos prendemos muito ao “usuário final”, o cliente, o carinha que está na outra ponta da feature, sem levar em conta todas as outras pessoas que também utilizarão a feature (time de suporte, time de operações, os próprios devs, por exemplo).

Alguns já devem ter lido ou ouvido  que “user stories devem ser INVEST”, e pra quem não leu/ouviu, é um acrônimo criado por Bill Wake em seu artigo “INVEST in Good Stories, and SMART Tasks” e reproduzido também por Mike Cohn em seu livro “User stories applied”.

São livros e artigos bem interessantes, e em um TL:DR, o que ele diz é que boas user stories possuem alguns atributos desejáveis. São eles: Independent, Negotiable, Valuable, Estimable, Small e Testable. Aqui, o que gostaria de chamar atenção são para 3 itens: Valuable, Estimable e Small. Lembramos sempre do “Valor”, mas esquecemos do Estimável e Pequena. Não uma estimativa mais apurada de esforço, pontos ou dias, mas algo que possa ajudar um Product Owner, por exemplo, a priorizar um backlog sabendo de uma duração próxima que o card terá. E principalmente, pequena, de forma a ser entregue em poucos dias entregando valor mais cedo.

Nos prendemos ao contexto de valor gerado pro usuário final, mas esquecemos que o valor é relativo. Além de ser algo que deve ser benéfico para outras pessoas dentro do processo, como o time de desenvolvimento, por exemplo. No caso de um card que vai gerar uma API que poderá ser utilizada por outros times, isso não gera um valor para o projeto como um todo? User stories técnicas não são user stories? Não devem entrar no backlog? Se formos pensar somente no “card escrito pelo usuário”, uma criação de API não entraria no backlog.

Então, vamos pensar no seguinte caso: o time X está trabalhando num projeto novo, o lançamento de um e-commerce e precisa desenvolver uma feature que deverá receber um pagamento via cartão de crédito, e após confirmado o pagamento envie por e-mail um documento em pdf listando os itens da compra realizada. Algo como “Eu, como cliente, gostaria de usar meu cartão para pagar a conta e, ao final, quero receber no meu e-mail um pdf listando todos os itens comprados”. Se formos pensar nesse card, o “valor” geral só será entregue quando o pdf chegar no e-mail do cliente, certo?

Essa US por si só, teria um tamanho considerável, levando em conta que será necessária uma integração com algum gateway de pagamento, para processar a compra no cartão de crédito, uma API de mensagens que faça a rotina de disparos de e-mail, e uma API geradora de docs capaz de gerar o arquivo PDF que o cliente espera. E também é provável que uma PoC, caso o time não tenha mexido com gateways de pagamento antes. Se formos pensar no tamanho dessa user story, ela poderia levar semanas para ser desenvolvida por completo, se considerarmos o “valor” esperado pelo cliente, o PDF no e-mail, dessa forma, não se encaixaria no Estimable e nem no Small. Mas uma API de envio de mensagens pode ser usada pelo time de marketing, por exemplo. O gateway de pagamento também já pode ser utilizado por outros times. Da mesma maneira, o gerador de PDF já tem valor para outras equipes dentro do projeto. Além de que, uma PoC também serve para validar uma hipótese, nos ajudando a mudar de rumo mais rápido, caso o conceito não seja provado. O que também, se formos pensar, é valor.

Dessa forma, esse “épico”, poderia ser quebrado como descrito acima, criando cerca de 4 US, que também geram valor sozinhas. Valor que provavelmente não será entregue somente ao cliente final, mas sim aos times de operações, marketing e suporte. Pensar no cliente externo é muito bom, mas devemos também pensar no cliente interno, aqueles envolvidos que quase sempre são esquecidos.

O conceito de valor é interpretativo demais, além de ser volátil e perecível. Tendo isso em vista, devemos ter bastante cuidado ao deixar de quebrar uma user story por achar que ela não está gerando o devido benefício, é importante lembrar que outras pessoas dentro do fluxo podem se beneficiar de um card quebrado. Dessa forma, se levamos semanas para entrega de uma user story, estamos depreciando o que poderia ter sido entregue, por conta da volatilidade. Fatiar cards, entregando histórias mais rápido auxilia numa geração de valor acelerada com risco reduzido da solução perecer.

E você? Como lida quando o assunto é a quebra de user stories dentro do seu time? Deixe sua opinião aí nos comentários.

***

Este artigo foi publicado originalmente em: http://blog.plataformatec.com.br/2017/04/user-stories-quebrar-ou-nao-quebrar-eis-a-questao/