Many-people-chatting-about-everything-learningHistórias de UsuáriosUser 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 PreparadaDefinition 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!