Boas histórias no Scrum devem entregar uma funcionalidade que signifique algo no dia-a-dia da área solicitante.
Sendo assim, deve ser facilmente validada e testada para que, após sua entrega, comece a ser utilizada independente de outras funcionalidades.
Parece fácil, não? E é sim! Menos é mais, então deixe de ser prolixo e siga algumas regras básicas.
Entendendo a necessidade
É importante conhecer muito bem a área de negócios para oferecer um produto que realmente atenda às necessidades da área usuária.
Esta é uma premissa antiga e que o Scrum derrubou imediatamente, pois não requer uma equipe de especialistas nos negócios.
Este passou a ser o papel do Product Owner (nosso bom e velho amigo PO) que deve conhecer muito bem a área de negócios que vai representar diante da equipe de desenvolvimento. Conhecendo todo o contexto, o PO deve ter a capacidade criar sínteses claras e objetivas das necessidades em módulos e, junto com Scrum Master e toda equipe de desenvolvimento, criar os pacotes de entrega (sprints). Sendo assim, o PO tem que “saber o que pedir” para que a equipe entregue algo que agregue valor.
Uma vez que o Product Owner soube fazer seu trabalho com clareza e conseguiu traduzir as necessidades, fica a cargo da equipe de desenvolvimento organizar essas informações em um pacote a ser entregue no final da sprint. Essas informações são traduzidas em pequenas histórias que serão representadas e organizadas em entregas que, no final da sprint, atenderão a necessidade descrita pelo Product Owner.
Comecei a ser prolixo? Sim, percebeu agora o que não pode acontecer?
Épicos
No começo a equipe pode criar uma história bem detalhada que será chamada de Épico (pode criar uma cerimônia exclusiva para esse debate).
Esta história serve apenas para que a equipe consiga enxergar a necessidade completa do PO. Em seguida, este Épico deve ser desmembrado em partes menores, chegando às histórias que darão origem às tasks do nosso quadro Kanban.
O resto você já sabe, não é mesmo? Fazer o Planning Poker, estabelecer as pontuações e afinidades de cada membro da equipe com as tasks. Se precisar, vale ler o artigo Artefatos e Ferramentas Scrum.
Mas aqui eu quero falar sobre como elaborar essas histórias de uma maneira eficiente.
Seguir o acrônimo INVEST
Independentes
A história deve ter significado próprio e autonomia funcional. Em outras palavras, ela deve ser capaz de executar algo que não tenha dependência de outras histórias. Por exemplo, subir uma foto para o servidor, referente ao cadastro do usuário. Subir a foto depende diretamente das informações do usuário para que o arquivo da imagem esteja referenciado no banco de dados com o código do usuário (por exemplo). Portanto não faz sentido separar em duas histórias. Para que a história seja independente, subir a foto e armazenar os dados do usuários devem estar dentro da mesma.
Negociáveis
Se uma história é independente, ou seja, não interfere na entrega de outra história, então ela pode ser negociável com Product Owner para ser entregue em outra sprint (por exemplo) sem afetar o valor da entrega a ser feita.
Valiosas
A história deve representar um valor de entrega (financeiro ou estratégico) para que seja um argumento mensurável durante eventuais negociações durante uma sprint.
Estimáveis
Se a história tem um valor, então ela deve ser quantificada e seu desenvolvimento representado em unidade de tempo (ou pontos) para que ela tenha um valor definido e possa ser negociada, quando necessário.
Sucintas
Uma história precisa ser bem elaborada mas ter o menor grau de complexidade possível. É mais fácil manipular funcionalidades pequenas em uma sprint, evitando eventuais retrabalhos ou demasiado gasto de tempo trilhando um caminho equivocado.
Testáveis
Se você conseguiu criar uma história atendendo a todos os itens descritos acima, então ela é completamente possível de ser testada e homologada antes de ser colocada em produção. Podemos estar falando de testes unitários ou testes integrados, mas se a história tem um tamanho compacto e baixa complexidade, então o teste será, relativamente, simples e rápido.
Diferentes prismas de uma história
Você pode adotar duas estratégias diferentes para elaborar suas histórias. Independente de qual delas você escolha, não esqueça de que elas devem seguir o acrônimo INVEST que expliquei agora a pouco.
Funções básicas
Você pode utilizar as funções de Criar, Consultar, Atualizar e Excluir informações, onde cada uma delas será representada por uma história. Normalmente é a forma mais utilizada porque tem uma compreensão mais fácil, principalmente porque está diretamente relacionada aos métodos de uma classe.
Etapas do processo
Aqui você vai abstrair um pouco mais e pensar nas entregas de negócios e suas importâncias para a área solicitante. Sendo assim, você poderá ter as funções mencionadas anteriormente entregues em sprints diferentes, pois as histórias serão elaboradas mediante o valor de negócios a serem entregues. Por exemplo, o PO pode deixar claro que, inicialmente, a maior prioridade está em consultar os dados existentes e fazer sua manutenção. Criar e excluir podem ficar para uma outra sprint e assim você monta a entrega atual com alguns relatórios, inclusive.
Como você deve ter percebido, chegamos à mais uma flexibilização no Scrum e que tudo vai depender das necessidades (e entendimentos) da empresa em lidar com seu Product Backlog.
Tenho mais dois assuntos importantes para tratar nos próximos artigos, onde vamos falar em como fazer quando há discordâncias entre usuários e a visão do PO, além de abordar sobre término anormal de uma sprint.
Até o próximo artigo!
Fonte: Federal Case Notes
