História do usuário sem fim
Vieram me perguntar, por que uma História do usuário de um determinado time, parece uma História sem fim. Ou seja, fica voltando de Sprint a Sprint.
Isso me inspirou a escrever esse artigo. Logo me lembrei do filme: A História sem fim, ops, entreguei minha idade.
No filme, o mundo da fantasia esta sumindo, mais no fim das contas, não acaba nunca. Igual a tal História do usuário, que quando parece que vai finalizar, persiste nas Sprints seguintes, KKKK. Agora vamos ver o por que.
Esse problema pode ser ocasionado por alguma das alternativas abaixo:
História do usuário mal refinadas
Independente do refinamento, ter ou não ter, sido realizado, estão surgindo dúvidas do time ao longo da Sprint. Em suma, isso ocasiona um atraso que provavelmente necessitará de um novo refinamento. Bem como, as vezes até retrabalho do que tinha sido desenvolvido, baseado no entendimento anterior.
História do usuário grande demais
Não quebrar as User Stories podem fazer elas se arrastarem pelas Sprints seguintes.
Alguns podem dizer que não quebra, por não perceber valor. A quebra diminui os riscos, e isso para mim é valor. Afinal, fazendo aos poucos, temos mais probabilidade de ir na direção certa. E se ainda assim, formos na direção errada, o estrago não será grande: de tempo, de dinheiro, de retrabalho etc.
História do usuário com Dependências externas
As User Stories que entram em bloqueio/impedimentos no meio de uma Sprint por conta de dependências externas, podem se arrastarem para as Sprints seguintes.
As vezes essa dependência aparece no meio da Sprint de surpresa. Mas se conseguirmos mapear antes, não devemos deixar essa User Story entrar, por que a probabilidade de dar problema é grande.
História do usuário passando por gargalo do time
Se você no seu time tem um gargalo (teoria das Restrições) é provável que possa acontecer de alguma User Story se arrastar para a Sprint seguinte.
Em muitos casos os QA são gargalos, mesmo que cada membro do time faça seus testes, ainda sim, o trabalho do QA vira gargalo no fim da Sprint.
Igualmente, se você tiver um desenvolvedor fora da média no time, os grandes pepinos acabam chegando nele, que acaba desenvolvendo a User Story dele e dando uma mão aos demais.
Isso pode ocasionar de alguma User Story ir para a Sprint seguinte, caso ele esteja sobrecarregado com as Stories deles e dos problemas dos demais.
História do usuário sendo priorizadas pelo PO por que já tem algum desenvolvimento
A avaliação que tem que ser feita pelo PO, é se ainda faz sentido continuar essa História, se ela ainda traz o benefício esperado. Ela pode voltar para o Backlog numa baixa prioridade, independente do desenvolvimento que tenha sido realizado. Em suma, Ela pode ser ou não ser concluída ao longo do projeto.
Em conclusão, devemos garantir que se as User Stories estão retornando nas Sprints seguintes, é pelo alto valor que deverá ser gerado.
Informações sobre a autora: Jacqueline Viana é Scrum Master e é apaixonada por agilidade.
