Histórias de Usuários – User Stories – são motivo de dúvidas para muitos iniciantes no Scrum, e as vezes até mesmo para praticantes com alguma experiência. Isso é comprovado inclusive pelas estatísticas de nosso Blog (com mais de 10 mil leitores/mês), que mostra que posts sobre User Stories estão sempre entre os mais procurados. Assim, vamos tentar enxergar Histórias de uma forma prática e simples. Essa série de posts é dedicada a isso.
Um projeto Scrum tem seus requisitos organizados em uma lista chamada Product Backlog. Assim, a grosso modo, os requisitos de um projeto ou produto são itens dessa lista, ou melhor, itens do Backlog. A forma mais utilizada para descrever esses itens é como User Stories, que aqui chamaremos somente de Histórias.
Uma História pode ser escrita da seguinte forma (Cohn, 2004): Um Ator quer Algo por um Motivo.
- O Ator é a representação de um papel de usuário, ou seja, de um tipo de usuário, como Secretária, Atleta, Cliente, Associado, Diretor, etc.
- O Algo é a meta do usuário ao utilizar o produto sendo criado. Deixa claro o que o usuário espera ao utilizar o produto. Algo como “emitir um relatório de vendas” ou “verificar os batimentos cardíacos”.
- O Motivo funciona como uma justificativa e ajuda o Time Scrum a entender a História e a necessidade do Ator. “Para premiar o melhor vendedor” e “para ajustar a intensidade do exercício” são exemplos de motivos.
Esse formato deixa clara a ideia de História: comunicar ao Time um “requisito”, ou seja, algo que precisa ser feito durante o desenvolvimento do produto ou projeto. Assim, o time deve ler a história e entender o que deve ser feito, eventualmente esclarecendo alguma dúvida com o PO.
Porém, será que somente uma descrição dessas é mesmo suficiente?
Nem sempre. Dependendo do tipo de produto/projeto sendo conduzido, da “intimidade” e do tempo do time com o mesmo, uma simples frase pode ser o suficiente. Mas na maioria das vezes isso não é verdade.
Como fazer então?
O Scrum também tem uma solução para isso: Definição de Preparada – Definition of Ready. 
Considera-se que uma história está preparada quando já foi refinada e detalhada o suficiente para que o Time possa trabalhar nela. Considerando que o próprio Time de Desenvolvimento deverá estimar e atender ao prescrito pela história, nada mais justo do que a definição do que uma história deverá apresentar para ser trabalhada ser definida pelo Time de Desenvolvimento com o PO. Isso é exatamente a Definição de Preparada – uma combinação entre PO e Time de Desenvolvimento sobre o que é necessário para uma história ser considerada preparada e consequentemente poder ser trabalhada em uma Sprint. Essa definição promove a transparência, deixando claro para todo o Time Scrum o necessário em termos de preparação e alinhando as expectativas do Time de Desenvolvimento e do PO.
Enquanto alguns times usam uma Definição de Preparada muito simples, outros incluem diversos itens:
- Artefatos necessários, como Modelos de Caos de Uso e Modelos de Negócio, Esboços de Telas, Maquetes, etc.;
- Características da história, como valor agregado bem definido;
- Critérios para a aceitação; e
- Capacidade do time, como o time ter os profissionais adequados para a realização da história, etc.
Tudo isso de acordo com o tipo de projeto sendo desenvolvido e com as características do Time. São definições tão importantes que no ScrumHalf registramo-as nas configurações de um projeto, para servirem como referência para o time.
Concluindo, as histórias balizam todo o trabalho a sendo realizado no projeto, e são, simplesmente, a expressão do que os usuários do produto desejam, que permita ao Time desenvolver o produto correto.
Mas que tipos de histórias existem? Como definir a granularidade ideal? Dá para estimar? Esses e outros assuntos abordaremos nos próximos posts.
Ah, e não esqueça de comentar com suas dúvidas. Se não a abordarmos ao longo da série, tratamos ao final.
Bom Scrum!
