As estórias do usuário (User Story) são a base para construir e desenvolver um produto eficaz utilizando a metodologia ágil Scrum. Basicamente essa estória consiste na descrição de uma tarefa por meio da uma receita, mas é muito mais do que isso. Para que os usuários se sintam mais motivados em realizar aquilo que está na descrição é fundamental que haja valor agregado nessa entrega. Confira a seguir como escrever estórias do usuário mais eficazes com Scrum.
Afinal, O Que São Estórias do Usuário?
Recebe o nome de estória do usuário ou User Story a descrição de uma necessidade do negócio cuja descrição é feita sob o ponto de visto do usuário. Trata-se de uma redução do 5W2H focando apenas nos três pontos mais cruciais: Quem, O que?, Por que?. É possível escrever essa estória de diversas formas desde que possua os três itens citados. A seguir alguns exemplos:
“Com o objetivo de (por que: motivo ou valor do negócio), com (quem: papel), eu devo (o que: ação ou função).”
“Sendo eu (quem: papel), gostaria (o que: meta) para (porque: valor que o negócio possui ou razão).”
Talvez você esteja pensando como é simples escrever a estória do usuário, mas saiba que não é bem assim, pequenos detalhes podem fazer toda a diferença. Continue lendo e entenda.
Como Escrever “Quem?”
Vamos apresentar a seguir um exemplo errado que num primeiro momento pode parecer estar certo:
“Eu, sendo o gerente, desejo que as imagens dos produtos apresentem zoom para que o cliente possa ter uma melhor experiência.”
O erro dessa estória está na contradição que apresenta em relação ao que diz o Manifesto Ágil que coloca em primeiro lugar a satisfação do cliente por meio de uma entrega contínua de um software que possua valor agregado. Haja vista que o objetivo é a satisfação do cliente a história não deveria estar do ponto de vista do gerente, ao fazer isso o seu negócio busca feedback na fonte errada. A entrega de valor deve ser feita para o usuário final.
Para que fique mais claro o usuário final é aquele que receberá o valor da história de maneira que a mesma deverá estar sob o seu ponto de vista. Definir o papel certo na hora de escrever a estória do usuário é determinante para a sua eficiência. Numa história que está bem escrita o usuário é especificado com detalhes, pergunte-se: Trata-se do usuário logado?; É usuário de que sistema?; Há uma persona definida?; Tem uma persona bem definida?. Quanto mais detalhes do usuário mais assertiva será a solução criada.
Como Escrever “O Que?”
Ilustração Sobre a Frase O que
Se há uma série de erros significativos no tópico de “Quem” há mais ainda no tópico de “O que”. Abaixo vamos apresentar um dos erros mais comuns nesse tópico:
“Eu, sendo usuário, desejo ter uma tela de login para acessar minhas informações com segurança.”
A pergunta básica é quem é o usuário que está preocupado e querendo uma tela para se logar. Esses erros de desejo dos usuários acontecem porque em boa parte das vezes estamos querendo achar uma solução simples na própria estória, algo que não é o objetivo. Essa é a representação de uma necessidade do empreendimento não devendo apresentar uma solução e sim demonstrar qual é o problema enfrentado pelo usuário ou pelo seu negócio.
Geralmente a estória é escrita pelo Product Owner, mas a solução deve ser determinada pelo time. Basicamente o problema deve ser apresentado na estória, mas solucionado posteriormente não fazendo parte dessa forma do seu texto. Considerando isso teríamos uma estória assertiva dessa forma:
“Eu, sendo usuário, desejo ter segurança para que somente eu possa acessar minhas informações.”
O time pode encontrar uma série de soluções para essa estória estando entre elas a criação de uma tela de login.
Como Escrever “Por Que?”
Os pontos principais a respeito do tópico de “Por quê?” são jamais deixar a sua estória sem um motivo ou usar qualquer desculpa. Lembre-se que esse tópico tem extrema relevância uma vez que consiste no motivo da escrita da sua estória. Para embasar esse tópico é possível tanto considerar a dor que seu usuário enfrenta como o valor que será gerado por essa solução.
O “Por Quê?” funciona como uma maneira de priorizar o Backlog sendo dessa forma um guia para que o time desenvolva a melhor solução criando inclusive métricas para avaliar se foram cumpridos todos os requisitos necessários. Esse, teoricamente, é o passo mais simples, pois geralmente já se tem um motivo bem claro no momento de escrever uma estória.
Ilustração sobre a Frase Por Que?
Use Critérios de Aceitação
O objetivo de criar e usar os critérios de aceitação (regras) é determinar quais são os critérios que devem ser atendidos para que se entenda que o processo chegou ao fim, tudo o que é necessário para que se tenha atendido ao usuário. Para entender melhor o que são essas regras vou apresentar um exemplo a seguir:
“Eu, sendo um comprador de carros, quero ter a oportunidade de fazer um test drive antes da compra, podendo dessa maneira ter um comparativo.”
A partir dessa estória do usuário é possível determinar dois critérios que são:
1 – O potencial comprador poderá fazer um test drive saindo com o carro da concessionária.
2 – Esse potencial comprador deverá, para poder sair da concessionária com o veículo, assinar um termo de compromisso.
Definir critérios não é obrigatório, mas pode tornar o processo de escrita da estória mais simples criando a possibilidade de serem usados como base para testes de aceitação.
Checklist INVEST
Buscando assegurar o máximo de qualidade para a criação de suas estórias é possível usar o acrônimo INVEST, cada letra determina um critério de qualidade diferente que deve ser considerado:
I de Independente (Independent)
Significa que as estórias devem apresentar independência entre si.
N de Negociável (Negotiable)
É importante que a estória esteja aberta para negociação, contar com recursos passíveis de serem negociados permitem que as pessoas tirem proveito do trabalho em conjunto compartilhando suas ideias e o sucesso do resultado.
V de Valioso (Valuable)
A estória em questão deve entregar o valor para o usuário final devendo dessa forma ser estruturada verticalmente.
E de Estimável (Estimable)
É importante que seja estimado um prazo de entrega.
S de Small (Pequeno)
Estórias eficientes são bem fatiadas, isto é, curtas.
T de Testável (Testable)
O time de criação deverá criar testes para que a história possa ser entregue.
Se a estória do usuário não está de acordo com um ou mais critérios do INVEST poderá ser negada para que seja reescrita.
Tamanho da Estória do Usuário
Para que uma estória do usuário seja considerada como boa deve ser curta, use como critério ela caber num sticky note. Lembre-se que escrever uma estória é tentar chegar a desburocratização, ou seja, promover um trabalho colaborativo como um convite para a realização de uma conversa. Se um desenvolvedor se depara com uma história que não entende deve procurar o Product Owner para tirar suas dúvidas, é crucial que haja o entendimento do esperado.
