Qual é a diferença entre histórias de usuários e requisitos?

Embora a maioria dos novos recursos deva ser definida a partir da perspectiva do usuário, na prática, ao definir os requisitos que as equipes de desenvolvimento precisam construir, muitas vezes ignoramos o “porquê” do ponto de vista do usuário. O foco de uma história de usuário está na experiência — o que a pessoa que usa o produto deseja alcançar. Os requisitos tradicionais focam na funcionalidade — o que o produto deve fazer. As diferenças restantes residem nas listas sutis, mas cruciais de “quem”, “como” e “quando”.

As histórias de usuário devem ser escritas em uma ou duas frases, capturando quem é o usuário, o que ele deseja e por quê. Uma estrutura simples para definir funcionalidades ou histórias de usuário é a seguinte:

Como um ______, quero ______, para que eu possa ______.

Exemplo:

Como um usuário, quero redefinir minha senha para que eu possa recuperar o acesso ao sistema caso eu a esqueça.

Apesar de objetivos diferentes, tanto as histórias de usuário quanto os requisitos visam, no fim das contas, criar um produto que os clientes amem.

O que é uma história de usuário?

Histórias de usuáriosão requisitos expressos a partir da perspectiva do usuário final. As histórias de usuário também podem ser referidas como épicas, temas ou funcionalidades, mas todas seguem o mesmo formato.

Essencialmente, uma história de usuário é um requisito claramente expresso. Por múltiplas razões, o formato de história de usuário tornou-se a forma mais popular de expressar requisitos no Agile:

• Foca na perspectiva da pessoa que usa ou é afetada pela solução.
• Define os requisitos em linguagem significativa para esse papel.
• Ajuda a esclarecer o propósito real por trás do requisito.
• Ajuda a definir requisitos de alto nível sem mergulhar cedo demais em detalhes de baixo nível.

Identifique os objetivos do usuário e considere imediatamente o valor de negócios de cada requisito dentro da história de usuário.

As histórias de usuário são geralmente consideradas compostas por três elementos — o 3C:

• CARD – Deve ser escrita em um cartão ou nota adesiva.
• Cconversa – Obtenha informações detalhadas do proprietário do produto (Proprietário do Produto).
• Cconfirmação – Certifique-se de que foi implementado corretamente. Deve atender aos critérios de aceitação do usuário.

Formato de História de Usuário

O formato para uma história de usuário é o seguinte:

Como um <papel>, Eu quero <objetivo>, para que <benefício>

Esses dois exemplos demonstram histórias de usuário em níveis diferentes, mas usando o mesmo formato:

No nível do projeto:

Como um <Diretor de Marketing>, Eu quero <melhorar o atendimento ao cliente>, para que <retivemos nossos clientes>.

• Escreva Metas SMART e INVEST para Histórias de Usuário
• Tema vs Épico vs História de Usuário vs Tarefa
• O que é DEEP na Lista de Produto?
• Como escrever a Visão do Produto para um Projeto Scrum?
• Como usar o Quadro Scrum para o Desenvolvimento Ágil?
• Quem cria itens da Lista de Produto ou histórias de usuário no Scrum?
• O que é Estimativa Ágil?
• O que é Ponto de História no Ágil? Como estimar uma História de Usuário?
• Divisão de Histórias de Usuário – Fatia Vertical vs Fatia Horizontal