Fatias mal feitas doem

Um caso real (e doloroso) de histórias mal fatiadas.

O Product Owner é responsável pelo produto backlog, sendo assim é necessário que o trabalho de priorizar, fatiar e descartar seja sempre bem feito a fim de cumprir o objetivo de maximizar o valor do produto e do trabalho da equipe de desenvolvimento.

Até ai tudo bem, mas o que acontece quando não funciona do jeito que deveria?

É o que vou contar agora. As próximas linhas são baseadas em fatos reais.

O CASO

A primeira parte foi entender a real necessidade do usuário, o seu problema. Esta parte não foi a mais difícil, tínhamos dados que mostravam que o usuário necessitava da exposição simples e objetiva de informações para acompanhamento adequado do seu negócio, facilitando assim seu dia a dia.

Então foi a hora de escrever as famosas histórias de usuário: Eu, como <pessoa usuária>, gostaria de tal <funcionalidade> a fim de resolver o <problema>.

Mas ter uma história enorme onde não seja possível entregar nenhum valor, não é algo relevante. Quando fatiamos facilitamos o trabalho, pois pensamos em algo simples, e automaticamente pensamos em algo FÁCIL e focamos no que é necessário para alcançar nosso objetivo.

Tendo fatias menores e simples é mais fácil: validar hipóteses, validar requisitos (exemplo: layout, área de toque da tela etc), reduzir incertezas no processo de desenvolvimento, reduzir a complexidade e os custos. Apenas para citar algumas das vantagens.

Então, partir para o fatiamento.

FATIANDO

Para fatiar, fui vendo o passo a passo do fluxo que a pessoa usuária faria no produto. Cada história representava uma parte deste fluxo, e o objetivo era que ao reunirmos todas pudéssemos ter algo completo, mas que ao longo do caminho pudesse ser validado alguma parte. Infelizmente não foi o que ocorreu, a primeira fatia era requisito obrigatório da segunda, a terceira fatia só poderia ser concluída com o término da primeira e da segunda, e assim por diante.

Isto gerou uma DOR enorme no time. Todos ficaram frustrados e desanimados, não conseguimos seguir com testes, não conseguimos fazer pequenas validações ou teste de experiência. A sprint parecia não ter fim.

E quanto mais perto estávamos do fim do período de desenvolvimento e claramente estávamos mais longe de atingir o objetivo de nossa sprint, mais o time tentava entregar, e mais claro ficava que as fatias estavam mal feitas, que nada podia seguir com assertividade sem o item anterior; e claro a insatisfação e o desgosto do time também cresciam.

Na Review, que é a cerimônias que marca o fim de um ciclo de desenvolvimento e onde apresentamos o que foi finalizado, objetivo da nossa sprint não tinha sido atingido! O time estava se sentido mal com o resultado, sentido que seu esforço não resultou em nada positivo e de valor para ser entregue, e nem vou dizer a dor que causou nos stakeholders. Sem contar em todo o desconforto e habilidade de comunicação para explicar aos stakeholders o motivo da sprint ter falhado.

Foi doloroso, mas nos ensinou uma boa lição.

A LIÇÃO

Uma fatia não é como uma cebola, cheia de camadas, pois as camadas individualmente não entregam valor, e não cumprem o papel de otimizar a validação de hipóteses. Logo um das primeiras característica das fatias é que elas são Independent, a história que representa aquela fatia deve ser independente das demais, a fim que por si só traga sentido e valor.

A segunda característica é que ela precisa ser Negotiable, ou seja, a história tem que ser possível de ser negociável, para que possa corresponder às mudanças que se fizerem necessárias, sejam de prioridade, valor ou de requisitos para conclusão.

Outro ponto é que ela precisa ser Valuable, sendo assim cada história precisa refletir claramente seu valor para o negócio. E também, a história precisa ser Estimable, isto significa que a história precisa ser bem detalhada para que possa ser estimada com maior precisão.

Além disso, as histórias precisam ser Small, afinal quando pensamos em algo simples e pequeno é mais fácil de trabalhar, fazer estimativas e realizar entregas. E por último, mas não menos importante, as histórias de usuário precisam ser Testable, para que os requisitos, critérios, procedimentos ou experiências possam ser validadas via teste.

Cada uma das características formam o acrônimo INVEST, criado por Bill Wake, é uma das formas para criar boas fatias e histórias de usuários que sejam concluídas com sucesso, de maneira assertiva e tempestiva.

Então, ao criar suas histórias, pensem se elas estão seguindo os atributos desenhados por Wake a fim de evitar dores com fatias ruins.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Abaixo algumas referências para continuar o estudo sobre fatiamento das histórias de usuários:

https://www.knowledge21.com.br/blog/fdp-do-product-owner/

https://medium.com/@karladiasn/user-stories-e-crit%C3%A9rios-de-aceita%C3%A7%C3%A3o-317c48403fcd

https://medium.com/nstech/como-quebrar-user-stories-ae382156729c

https://marcobaccaro.wordpress.com/2013/02/15/invest-user-story/