User Story – História de Usuário

No processo de desenvolvimento de Produtos, expressar a necessidade do usuário final de forma textual, clara e objetiva é um dos maiores desafios que o Product Owner pode enfrentar.

Primeiramente porque usuários tem dificuldades de expressar as dores e necessidades, bem como priorizar e identificar onde estão. Em segundo lugar porque o Dono do Produto precisa garantir que a comunicação seja feita com sucesso com o Time de Desenvolvimento que vai desenvolver a solução.

As Histórias de Usuário (User Story) foram criadas exatamente com este propósito de apoiar e transmitir a necessidade do usuário utilizando uma linguagem simples e clara, facilitando o entendimento entre as partes e maior acerto no desenvolvimento do Produto com base na especificação.

O que são Histórias de Usuário?

A melhor e mais sucinta definição para uma História de Usuário está no Guia do Scrum:

… uma descrição concisa de uma necessidade do usuário do produto sob o ponto de vista deste usuário.

Uma história é a representação clara e informal que expressa a necessidade e/ou requisito de um potencial usuário. Também pode ser considerada uma parte de um objetivo final. A User Story é a menor unidade de trabalho com base na necessidade do cliente final que vai utilizar e/ou interagir com o Produto.

O objetivo da História é expressar, em poucas palavras, as dores e necessidades, propor critérios mínimos para aceitação e o valor de negócio agregado de uma forma clara, limpa e leve. Nesse ponto, o PO precisa ser extremamente assertivo.

 

Assine nossa Newsletter e fique sempre atualizado com nossos artigos!

 

Vantagens de utilizar histórias de usuário

As Histórias de Usuário permitem boas vantagens e diferenciais:

• Permite visualizar melhor o Valor de Negócio agregado ao usuário.
• É possível obter maior conhecimento das Personas e suas necessidades.
• Por não ter uma gama de requisitos pré-definidos, permite ao Time de Desenvolvimento maior flexibilidade e criatividade na criação do Produto – provocando a autonomia da equipe.
• Linguagem mais leve e fácil de entendimento entre todas as partes interessadas.
• Maior rapidez e agilidade no refinamento devido à leveza, simplicidade, praticidade e tamanho.

O que não é História de Usuário

É preciso tomar cuidado para não confundir a história de usuário com outros conceitos:

• User Story não é Especificação de Requisitos: pode conter um ou mais artefatos de requisitos vinculados à História, porém a User Story não é o próprio requisito detalhado.
• Histórias não são Casos de Uso: assim como a ER, Stories não são casos de uso.
• User Story possui Linguagem Técnica: histórias tem linguagens fáceis e informais.
• História de Usuário não é Documentação oficial (há controvérsia): sendo o ponto mais polêmico deste tópico, a história não é (pelo menos não deveria) servir de documentação oficial de um Produto.

 

Estrutura da User Story

 

A história de usuário é formada, basicamente, por três informações:

Informações Gerais

Informações para rastreamento e identificação rápida da história no Backlog. Essas informações normalmente são:

• número identificador
• Projeto/Iniciativa (às vezes)
• título/nome da história

Exemplos práticos:

• 00001 – Enviar notificação para meus filhos
• 00002 – Meu Lar – Receber reclamação da cuidadora

Descrição

Sendo a parte mais importante da User Story e a própria definição já aqui exposta, a Descrição apresenta o tipo de usuário, necessidade/dor e objetivo/propósito da necessidade.

Tal descrição contém, basicamente, a estrutura: “Como [persona], eu [quero], [para que].”.

De modo que:

• Como + {Persona} – representação fictícia do cliente/usuário ideal: Para quem estamos criando? Qual o perfil deste usuário? Pode ser utilizado um nome, cargo ou perfil.
• Quero – necessidade/dor do usuário: Qual a necessidade? Qual dor estamos solucionando? Não deve ter tratamento de implementação técnica, mas sim de necessidade do mundo real.
• Para que – valor de negócio envolvido / objetivo final: Qual o ganho desta história para meu usuário? Qual o benefício agregado? Esta resposta deve estar totalmente de acordo com o “Quero”.

Exemplos Práticos:

• Como Dona Helena, mãe de 2 filhos, Quero que seja possível visualizar o que minhas crianças estão “aprontando” dentro de casa Para que eu possa ter ciência do que se passa em meu lar enquanto eu trabalho.
• Como Pai, Quero receber notificações da professora referente a qualquer informação pertinente e importante aos meus filhos Para que eu possa conversar com ele mais tarde e/ou retornar mais breve para casa caso seja necessário.

Critérios de Aceite

Os Critérios de Aceitação representam as condições mínimas necessárias para que a história possa ser considerada entregue após a construção do Produto. Os critérios de aceitação descrevem as informações necessárias para o funcionamento do Produto com base na Descrição.

Os critérios de aceite devem indicar condições, restrições e as regras de negócio do Produto. Essas informações precisam estar de acordo com as Informações Gerais, Descrição e todas as demais características já apresentadas aqui.

Exemplos Práticos:

• A notificação deverá ser recebida via mensagem de celular
• A notificação deve conter as informações básicas dos meus filhos
• Deverá conter opção de visualização de informações mais detalhadas e fotos dos meus filhos
• Os relatórios semanais devem conter o resumo da atividades, alimentação e ocorrências com meus filhos em formato de gráficos de barra

** Note que não tem informações sistêmicas ou proposta de solução. Isso permite à equipe de desenvolvimento maior autonomia e criatividade.

 

A História de Usuário, o Backlog do Produto e o Product Owner

Histórias de usuários são largamente utilizadas no Backlog do Produto para as metodologias ágeis. Apesar disto, vale lembrar que o Guia Oficial do Scrum não define qual tipo de artefato utilizar.

O Backlog do Produto pode ser facilmente composto por Histórias de Usuários. Os itens do Backlog que estão no topo devem ser mais detalhados, pois estes serão os próximos a serem desenvolvidos. Logo, os itens de menor relevância devem ter menos detalhes ou servirão como ‘memória’ de desenvolvimento para uma futura avaliação de valor.

O Product Owner precisa ter a capacidade de entender e conversar com os usuários, levantar histórias de usuários consistentes conforme tudo que apresentamos por aqui e priorizar o Backlog do Produto com qualidade. Lembrando que todas estas atividades devem ser realizadas buscando o respectivo Valor de Negócio do Produto.