Calma, não vamos falar da técnica em si, utilizada por Júlio Cesar, detalhada em seu livro De Bello Gallico (Guerra das Gálias), que explicou como a vitória romana na guerra gaulesa era essencialmente uma política de “dividir” seus inimigos, aliar com tribos individuais durante suas disputas com adversários locais.
Trazendo isso para o contexto Ágil, gosto do termo dividir para conquistar quando tratamos de SPLIT de estórias de usuário, que consiste em dividir uma estoria em diversas outras menores para que possamos entregar valor sempre, que a estória possa ser planejada de maneira mais eficaz, mais acertiva e claro, que possamos entrar em um processo de entrega daquilo que é suposto entregarmos (em termos de story points por iteração).
A resposta é simples: "Dar visibilidade do que está sendo feito". É muito cômodo pra nós, do time de desenvolvimento pegar coisas para fazer sem nos preocupar com que outras pessoas pensam, ou melhor, sobre o que o nosso utilizador final pensa, no que nossos stakeholders pensam, no que nosso produto pensa e isso é algo muito comum, porque somos acostumados a tomar pancadas e não nos preocuparmos com isso, pois pensamos que a empresa vai sobreviver ou pensamentos do tipo "novidade estarem chateados conosco por não entregarmos DE NOVO".
Outro motivo que eu uso para incentivar a divisão de estória é para evitarmos todo sprint ter perguntas de "Quando vai ficar pronto?", "Nossa, faz dois sprints que a estória não muda de status, o que está acontecendo?" e por ai vai.
Eu sou um profissional que odeia passar vergonha e vamos lá, começar uma estória, dizer que vamos entregar no final do sprint e levar 4 para terminar é motivo de muita vergonha, é gostar de levar na cara e ser taxado de incompetente.
Eu entendo que é um complicado dividir, mas custa nada parar um pouco para pensar em como podemos fragmentar a estória, e por isso vou dar algumas dicas que foram obtidas dos livros "Agile Estimating and Planning" e "Clean Agile - Back to Basis" do Bob Martin.
-
Dê o primeiro passo e decida o que é uma estória grande, ou seja, você pode definir 13 como uma estória muito grande e complexa e decidir não colocar isso dentro de um sprint. Sei que vai doer, mas não aceite e não se submeta a prometer uma estória que você sabe que não vai cumprir.
-
Após decidir, que sejamos honestos em nossas estimativas, ou seja, se temos duas estórias com 8 pontos, mas uma é mais difícil que a outra, essa deve ser 13, logo, não vai entrar, logo, DEVE ser dividida em várias partes.
-
Estime novamente cada fragmento da estória, lembrando que devemos comparar inclusive os fragmentos, ou seja, não é porque a estória é de 13 que eu tenho que fragmentar em duas de 5 story points e uma de 3 story points. O exercício de estimar é interessante, porque na comparação dos fragmentos podemos ver que o 13 não era bem 13 e que era bem mais que isso, como ocorreu semanas atrás no time que eu atuo, onde ao dividirmos, chegamos em um fragmento que era outro 13 e dividimos de novo e no final chegamos a ter 12 estorias, totalizando em quase 47 story points e lembre-se, derivamos uma estória de apenas 13 em 47 story points só utilizando a comparação como parâmetro para estimar.
OBS.: Se o time ainda não possui maturidade para duas ou mais pessoas trabalharem em cada fragmento da estória, priorize os fragmentos, suba uma estória para o sprint e as demais fiquem priorizadas no backlog. Digo isso porque sabemos que nem sempre é possível escrever uma estória utilizando de maneira INVEST e que leva tempo para o time de desenvolvimento passar a trabalhar em pair ou ambos no mesmo contexto.
Um maneira interessante, e que eu aprendi no momento em que eu deixei o waterfall, foi que criar tarefas no momento do planejamento ajuda a ter sucesso na entrega e melhor ainda, quando eu divido uma estória em diversas sub tarefas, consigo perceber o tamanho real do que nos espera.
Infelizmente na maioria dos times, quando quebramos tarfas, pegamos alguns contextos macros e colocamos como tarefa, o que faz estorias muito grandes com apenas quatro tarefas, o que é ruim, porque gera uma expectativa muito grande para nossa área de produto, que vai ver uma estoria com quatro tarefas e vai achar que aquilo é pequeno e o resultado já sabemos, não vamos entregar, área de produto vai ficar chateada, vai gerar incertezas e cobranças, bla bla bla.
Então além de quebrar, que possamos pensar e incentivar a quebra de tarefas e sub-tarefas de até um dia para serem feitas. Isso vai ajudar a ter visibilidade real do que é necessário ser feito para que aquela estoria possa ir para produção e o mais interessante, quando realizamos esse exercício de pensar em tarefas de até um dia, conseguimos chegar as vezes na conclusão de que estimamos muito abaixo ou muito acima, o que pode fazer nossa estimativa mudar. Esse percepção faz com que aos poucos, vamos tendo maturidade em planejar e estimar estorias.
Sim, invistam tempo comparando o esforço entre duas ou mais estorias, pois assim conseguimos voltar um bocado ao passado para conseguir prever o futuro.
Infelizmente as pessoas não gostam de ficar comparando porque geralmente a reunião de planejamento é curta, as pessoas ficam com aquele estresse emocional de querer sair de uma sala de reunião o quanto antes, MAS, se fizermos o exercício e comparar, de quebrar em tasks de até um dia, melhoramos o humor no planning e passamos a enxergar valor necessário para que ele possa ser o mais acertivo possível e para que possamos passar com mais transparência o que realmente é necessário para que aquela feature possa estar em produção o quanto antes.
Crie uma régua com estorias já entregues com suas pontuações ou qualquer métrica que seja utilizada para fazer o comparativo, e sempre esteja atualizando essa régua e com isso podemos usar sempre uma referência.
A parte do planejamento é a mais importante em qualquer modelo de trabalho, seja ele waterfall ou ágil, porque a partir do valor que é dado no planejamento, as features que nos propomos a entregar, começam a de fato serem entregues.
Sempre escutei que toda estimativa é burra, porém, quanto mais acertivo eu for, melhor será, porque eu reduzo a capacidade de errar e quando eu tenho o mindset voltado para que toda estimativa é burra, a porcentagem do meu erro pode subir, causando assim distúrbios de todos os lados, que gera pressão, que gera turnover.
Portanto, invistam tempo planejando as coisas, nem que leve o dia inteiro, mas invistam esse tempo planejando ponto a ponto, abram o código e busquem aquilo que é suposto fazer para que as estorias fiquem o mais granular possível, para que eu possa entender o que eu posso deixar com uma prioridade menor, que consigamos deixar de fazer algo porque é irrelevante para a feature em questão.
Planejar exige tempo e disposição, portanto, faça.