A situação da tirinha ao lado pode ter sido vivenciado por muitas equipes. Aquela velha situação onde achávamos estar estimando uma historia, e sem nos dar conta, estávamos com um verdadeiro épico nas mãos. O resultado não poderia ser diferente da tirinha acima. Acabamos construindo um carro popular enquanto o cliente estava pensando que iria obter um carro esportivo.

Mas e aquele caso em que o cliente espera o carro esportivo, mas o carro popular pode resolver o problema dele, afinal, se ele estava sem carro algum, neste caso, pode ser uma solução imediatista.

Ainda, imagine que os requisitos mudaram, e quando você estava construindo o carro esportivo, o cliente agora queria o carro popular. Pode acontecer não é verdade? O problema descrito na historinha acima é muito comum: a dificuldade em entender  as necessidades do cliente. E se o objetivo estiver claro, quais as dificuldades em realizá-lo, como devemos dividir o problema para que o objetivo seja alcançado mais rapidamente.

Se tivéssemos dividido o projeto do carro popular em pequenas partes tais como: confeccionar rodas, confeccionar pneus,  criar design do chassi, criar design do farol dianteiro, confeccionar motor, etc.Se tivéssemos reuniões de rotina demostrando a evolução do trabalho, poderíamos, desta forma, ter a certeza que estamos atendendo aos requisitos de forma adequada, e poderíamos até atender a possíveis mudanças nos requisitos, caso assim fosse necessário.

Seja lá qual for objetivo, um projeto de software ou algo totalmente diferente, devemos construir rapidamente o suficiente para resolver o problema de agora.Comece com o problema, decomponha-o em problemas menores e os priorize. Então trabalhe em um problema de cada vez.

As equipes muitas vezes enfrentam problemas por estar trabalhando com historias mal divididas. Histórias muito grandes, ou muito pequena, ou muito confusa.

Devemos dividir as histórias em pedaços pequenos de funcionalidade. Uma única história normalmente é a menor parte discreta de funcionalidade que adiciona valor ao negócio. O que também é importante em uma user story, é que ela deve ser completa, ou seja, ela deve fornecer um fluxo completo de experiência ao usuário. Ela deve levar o usuário de um ponto de partida a um ponto de chegada.

Ao dividir uma grande user story em várias menores, lembre-se de garantir que a historia tem o fluxo de usuário completo. Divida as histórias horizontalmente e não verticalmente.Uma história dividida horizontalmente irá mostrar um fluxo ou caminho único em que o usuário poderá executar. Por exemplo, um fluxo de pagamento que cobre a mais simples funcionalidade que um simples pagamento deve contemplar. Embora não seja permitido alterar o modo de pagamento, ainda sim o usuário poderá chegar a um fim útil para ele.Uma história dividia verticalmente irá mostrar múltiplos caminho por um fluxo, mas parará antes que o fluxo alcance algum objetivo de utilidade.Dividir uma história verticalmente ainda lhe faz perder a capacidade de testar o fluxo por completo.

Um fluxo incompleto, além de não adicionar valor ao negócio ou ao produto, faz com que as equipes tenham trabalhar extra para construir soluções efetivas que cubram a incompletude do fluxo.Pense em dividir os fluxos da aplicação em pequenas camadas horizontais, e conforme for avançando, adicione as outras funcionalidades na forma de outras pequenas camadas horizontais, isto é, adicione uma história nova.