​​​História de usuário é uma descrição curta e simples de uma funcionalidade do ponto de vista do usuário final.

Ela ajuda a:

• Guiar o desenvolvimento com foco no valor entregue

• Criar alinhamento entre Product Owner, DEV, QA e UX

• Servir como base para teste

​​

​

 Formato clássico:

Como [tipo de usuário]
Quero [uma ação ou funcionalidade]
Para que [benefício ou valor entregue]

​

Como cliente do e-commerce
Quero visualizar meus pedidos anteriores
Para que eu possa acompanhar minhas compras
 

​

 Escrita eficiente em Gherkin

​

O Gherkin serve pra transformar a história em casos de teste legíveis por humanos e máquinas, usados tanto por testes manuais quanto automatizados.

​

 Regras para boa escrita em Gherkin:

• Simples, clara e objetiva

• Um cenário = um fluxo de teste

• Usar linguagem de negócio

• Incluir dados representativos (ex: produtos, status, códigos)

 

Estrutura:

  Funcionalidade: Histórico de Pedidos

  Cenário: Exibir pedidos finalizados
  Dado que o cliente está logado no sistema
  E acessa o menu “Meus Pedidos”
  Quando ele visualizar a lista de pedidos
  Então ele deve ver os pedidos com status "Entregue"

​

 

Exemplos de histórias de usuário

​

 API – Consulta de Saldo do Cliente

Como cliente logado
Quero consultar meu saldo atual via API
Para que eu possa visualizar meu limite disponível nos canais digitais

Critérios de aceitação:

• Deve retornar saldo, data de atualização e moeda

• A resposta deve seguir padrão JSON

• A API deve estar protegida por token de autenticação

 

Tela – Histórico de Transações

Como cliente do app
Quero visualizar o histórico das minhas últimas transações bancárias
Para que eu possa acompanhar movimentações da minha conta

Critérios de aceitação:

• Exibir data, tipo de transação, valor e descrição

• Permitir filtro por data

• Exibir as 10 últimas transações por padrão

• A interface deve estar alinhada com o novo design system

 

Financeiro – Geração de Boleto

Como cliente com pagamento em aberto
Quero gerar o boleto da minha fatura atual
Para que eu possa realizar o pagamento dentro do prazo

Critérios de aceitação:

• A geração deve incluir vencimento, valor e código de barras

• O boleto deve estar disponível em PDF

• Deve ser possível copiar o código de barras

• A API de geração deve validar se a fatura está vencida antes de emitir o boleto

 

Segurança – Recuperar Senha

Como usuário que esqueceu a senha
Quero recuperar minha senha via e-mail
Para que eu possa acessar minha conta novamente com segurança

Critérios de aceitação:

• O link enviado por e-mail deve expirar em 15 minutos

• A nova senha deve ter pelo menos 8 caracteres, 1 número e 1 letra maiúscula

• A recuperação deve ser auditada no log de segurança

 

Integração – Enviar Notificação via Kafka

Como sistema financeiro interno
Quero enviar um evento para o tópico Kafka após o pagamento ser confirmado
Para que outros sistemas possam reagir ao status do pagamento

Critérios de aceitação:

• O evento deve conter ID do pagamento, status, timestamp e CPF do cliente

• O envio deve ser assíncrono

• Em caso de falha, deve ser registrado e reprocessado

​

​

Critério de Aceite 

O que é:

Critérios de aceite são regras objetivas que definem quando uma história de usuário pode ser considerada funcionalmente correta e pronta para ser aceita pelo Product Owner (PO).

São condições mínimas e verificáveis, escritas antes ou junto com a história, que orientam:

• O que deve funcionar

• O que deve ser validado

• Limites e exceções

 Importância:

• Evita mal-entendidos entre DEV, QA, PO e UX

• Garante foco no valor do negócio

• Serve de base para criação de cenários de teste

• Ajuda na automação de testes com Cucumber/Gherkin

• Define claramente o que é sucesso na entrega

 Exemplo prático:

História: Como cliente, quero visualizar meu saldo bancário para acompanhar minha conta

Critérios de aceite:

• O saldo deve ser retornado com duas casas decimais

• O valor deve estar em reais (BRL)

• Deve ser exibida a data da última atualização

• A API deve retornar código 200 com conteúdo válido

• Se o cliente estiver deslogado, deve retornar 401

​

 Definição de Pronto (Definition of Ready - DoR)

 O que é:

É uma checklist acordada pelo time que define quando uma história está pronta para entrar em desenvolvimento.

Ela garante que a história esteja madura, clara e com todos os insumos necessários para começar o trabalho sem dúvidas.

 Importância:

• Evita histórias "pela metade" sendo desenvolvidas

• Minimiza retrabalho e interrupções

• Facilita a planejamento da sprint

• Ajuda o time a dizer “não está pronto para desenvolver”

• Fortalece o papel de QA e UX desde o início

Exemplo de checklist – Definição de Pronto:

• História de usuário escrita no formato correto

• Critérios de aceite claros e objetivos

• Regras de negócio discutidas

• Protótipo disponível (se houver interface)

• Dependências mapeadas

• Dados de teste definidos (para QA e DEV)

• API contratada/documentada (se houver)

• Pontuada e priorizada

​

​

Diferença entre Critério de Aceite e Definição de Pronto:

​

Critério de Aceite - Define o que precisa estar funcionando para a história ser considerada "feita e aceita"

​

Definição de Pronto - Define o que precisa estar preparado antes da história entrar em desenvolvimento

​​

Uma história, várias tarefas (quebra técnica)

Uma única história de usuário pode (e deve!) ser dividida em múltiplas tarefas técnicas, como:

​

Tipo de Tarefa: Modelagem do banco

• Responsável: DEV

• Exemplo: Criar tabela orders

​

Tipo de Tarefa: API backend

• Responsável: DEV

• Exemplo: Criar endpoint GET /orders por usuário

​

 Tipo de Tarefa: Teste da API

• Responsável: QA ou DEV

• Exemplo: Validar o retorno da API com status code 200 e conteúdo esperado

​

 Tipo de Tarefa: Criação de tela

• Responsável: DEV

• Exemplo: Desenvolver componente em React para exibir o histórico de pedidos

​

Tipo de Tarefa: Teste da interface

• Responsável: QA

• Exemplo: Validar a renderização da tela com mock de pedidos, checando campos e layout

​

 Estimativas (Story Points, tempo e limite por sprint)

​

 O que é 1 ponto?

​

• Representa uma unidade de complexidade relativa

• Pode SIM ser aproximadamente igual a 1 hora (em squads que escolhem esse critério) — embora o ágil prefira complexidade a tempo.

 

 

💡 Dica prática:
Se você usa "1 ponto = 1 hora" e sua sprint tem 40h úteis por dev, o máximo seria 40 pontos. Mas na prática,

considere 60% da capacidade (24 pontos por dev) para absorver reuniões, bugs e ajustes.

​

 Sprint com entregas pequenas

​​Boa prática:

• Quebre grandes funcionalidades em entregas incrementais.

• Evite deixar para integrar só no final da sprint.

​

 Exemplo prático:

​Sprint 1

• Backend: GET /orders, modelagem e testes

• API testada com Postman ou RestAssured

• Frontend com tela mockada, apenas layout

• ​​

Sprint 2

• Integração front com API real

• Ajustes visuais

• Testes funcionais e exploratórios

 

Exemplo completo de jornada DEV + QA

​
Tarefas (quebra por função):

​

Tarefa                                               Pontos   Responsável    Descrição
Criar endpoint /orders/{id}                      3             DEV            Retorna pedido por ID
Testes unitários da API                           1              DEV            Cobertura mínima 80%
Testes da API (RestAssured)                     2             QA            Validar código, corpo, mensagens
Componente de tela                               3             DEV            Criar modal ou página
Integração com backend                          2              DEV            Fazer chamada e exibir dados
Testes funcionais (manual ou Selenium)    3              QA       Validar se tudo aparece corretamente
Teste exploratório                                  2               QA            Cobrir caminhos não mapeados

​

Pontuação total por Sprint (referência prática)

​

Cargo             Capacidade (horas úteis)    % alocação em tarefas    Pontos médios
DEV Pleno               40h                               60%                     24 pontos
QA Pleno                40h                               60%                      20–24 pontos

​

Obs: Se o time estiver muito maduro, pode usar até 75% da capacidade para tarefas técnicas.

​

Entregas parciais em sprints curtas