Backlog e requisitos ágeis: histórias de usuário, critérios e fatiamento

Backlog como ferramenta de execução (não como lista de desejos)

Em projetos ágeis, o backlog é um artefato vivo que traduz necessidades em itens executáveis, priorizáveis e testáveis. A qualidade do backlog depende menos de “quantidade de itens” e mais de quão bem cada item ajuda o time a: (1) entender o problema, (2) entregar valor em incrementos pequenos, (3) validar rapidamente com stakeholders e (4) reduzir risco por aprendizado contínuo.

Um item de backlog útil costuma conter: intenção (por que isso importa), escopo mínimo (o que será entregue agora), critérios de aceitação (como saber que está certo) e notas de descoberta (o que ainda é hipótese).

Formatos para capturar necessidades: histórias de usuário e Jobs-to-be-Done

Histórias de usuário (User Stories)

Histórias de usuário descrevem uma necessidade do ponto de vista de alguém que se beneficia do resultado. O objetivo é criar um “contrato de conversa”: curto o suficiente para incentivar diálogo, mas específico o suficiente para orientar implementação e teste.

Modelo clássico:

Como [tipo de usuário/persona], eu quero [capacidade/ação], para [benefício/resultado].

Boas práticas:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Foque em resultado (benefício) e não em solução técnica.
• Evite “Como sistema…” (a menos que represente um agente real e necessário, como um serviço externo).
• Use linguagem do domínio (termos que stakeholders reconhecem).
• Escreva para ser fatiável: uma história grande deve virar várias pequenas.

Jobs-to-be-Done (JTBD) quando aplicável

JTBD é útil quando o foco é entender a “tarefa” que a pessoa tenta realizar, independentemente de persona ou segmento. Ajuda especialmente em produtos com múltiplos perfis de usuário, ou quando o comportamento é mais importante que o cargo.

Modelo JTBD:

Quando [situação], eu quero [motivação/ação], para que eu possa [resultado esperado].

Quando preferir JTBD:

• Você percebe que personas não explicam bem o comportamento (pessoas diferentes fazem o mesmo “job”).
• O problema é recorrente e contextual (ex.: “quando estou com pressa”, “quando estou sem internet”).
• Você quer mapear concorrência real (inclui soluções alternativas e “gambiarras”).

Critérios de aceitação e Definition of Done: tornando “pronto” verificável

Critérios de aceitação (CA)

Critérios de aceitação descrevem condições observáveis que precisam ser verdadeiras para considerar a história atendida. Eles reduzem ambiguidade, alinham expectativas e orientam testes.

Formato recomendado: Given/When/Then (Gherkin)

Dado que [contexto inicial] (Given)\nQuando [ação/evento] (When)\nEntão [resultado esperado] (Then)

Exemplo (história: “Como cliente, quero redefinir minha senha para recuperar acesso”):

• Dado que o cliente informou um e-mail cadastrado Quando solicitar redefinição Então deve receber um e-mail com link válido por 30 minutos.
• Dado que o link expirou Quando o cliente tentar usá-lo Então o sistema deve solicitar novo pedido de redefinição.
• Dado que a nova senha não atende política mínima Quando o cliente confirmar Então deve ver mensagem clara com requisitos.

Checklist de qualidade dos CA:

• Testáveis (alguém consegue verificar objetivamente?).
• Completos para o fatiamento atual (não para “o futuro”).
• Sem prescrever UI em excesso (a menos que seja requisito real).
• Incluem casos negativos relevantes (erros, limites, permissões).

Definition of Done (DoD)

DoD é um acordo do time sobre o que significa “entregue com qualidade” para qualquer item. Diferente dos critérios de aceitação (que são específicos da história), a DoD é transversal.

Exemplo de DoD (ajuste ao seu contexto):

• Código revisado (peer review) e integrado na branch principal.
• Testes automatizados relevantes criados/atualizados e passando.
• Critérios de aceitação atendidos e evidenciados (print/log/relatório).
• Sem débitos críticos de segurança/performance conhecidos para o escopo.
• Documentação mínima atualizada (ex.: notas de release, instruções de uso interno).
• Pronto para deploy (mesmo que o deploy ocorra em outro momento).

Armadilhas comuns:

• DoD “flexível demais” (vira opinião e gera retrabalho).
• DoD “grande demais” para o estágio do produto (engessa e reduz fluxo).
• Confundir DoD com “Definition of Ready” (critérios para iniciar).

Modelos de histórias: bons e ruins (com correções)

Exemplo 1: história boa (orientada a valor)

História:

Como analista financeiro, eu quero exportar o relatório mensal em CSV, para consolidar dados no meu modelo de fechamento.

Por que é boa: tem usuário claro, ação objetiva, benefício mensurável (consolidar no fechamento).

Critérios de aceitação (exemplo):

• Dado que estou no relatório mensal Quando clicar em “Exportar CSV” Então devo baixar um arquivo com colunas A, B, C e cabeçalho.
• Dado que o relatório tem filtros aplicados Quando exportar Então o CSV deve refletir os filtros.

Exemplo 2: história ruim (vaga e não testável)

História ruim:

Como usuário, eu quero que o sistema seja rápido.

Problemas: “rápido” é subjetivo; não há contexto nem cenário; não orienta implementação.

Correção (fatiada e testável):

Como atendente, eu quero que a busca de clientes retorne resultados em até 2 segundos, para reduzir tempo de atendimento no balcão.

Critérios de aceitação:

• Dado que existem mais de 100 mil clientes Quando eu buscar por CPF Então devo ver o resultado em até 2 segundos em 95% das tentativas.

Exemplo 3: história ruim (solução disfarçada de requisito)

História ruim:

Como usuário, eu quero um botão azul no canto superior direito para enviar o formulário.

Problemas: prescreve UI; pode não ser a melhor solução; não explicita o objetivo.

Correção (foco no resultado):

Como cliente, eu quero enviar o formulário de cadastro com facilidade, para concluir meu cadastro sem erros.

Critérios de aceitação:

• Dado que preenchi campos obrigatórios Quando eu enviar Então devo ver confirmação e número de protocolo.
• Dado que há campos inválidos Quando eu tentar enviar Então devo ver quais campos corrigir e por quê.

Fatiamento (Vertical Slicing): entregar valor em fatias finas

Fatiamento vertical significa dividir trabalho por “capacidade completa” (de ponta a ponta) e não por camadas técnicas (front-end separado de back-end, separado de banco). Uma fatia vertical pequena gera um incremento utilizável e validável.

Como reconhecer fatiamento horizontal (e evitar)

Exemplo de decomposição horizontal (ruim para validação):

• Criar tabela no banco
• Criar endpoint
• Criar tela
• Adicionar validações

Isso pode ser necessário como tarefas técnicas, mas não deveria ser a forma principal de organizar o backlog, porque não entrega valor validável até o final.

Exemplo de fatiamento vertical (melhor)

Épico: “Cadastro de clientes”

Fatias verticais possíveis:

• Cadastro mínimo com nome + e-mail + confirmação (fluxo completo)
• Validação de e-mail já existente (fluxo completo)
• Campos adicionais (telefone, endereço) (fluxo completo)
• Upload de documento (fluxo completo)

Técnicas práticas de fatiamento

• Por fluxo principal vs. exceções: primeiro o “caminho feliz”, depois erros e bordas (sem ignorar riscos críticos).
• Por regras de negócio: implemente primeiro a regra mais comum, depois variantes.
• Por segmento/escopo: primeiro um grupo pequeno (ex.: apenas clientes pessoa física), depois expanda.
• Por operação CRUD com valor: às vezes “Criar” já gera valor; “Editar” e “Excluir” podem vir depois.
• Por nível de automação: primeiro manual assistido (com controles), depois automatize.
• Por risco: antecipe fatias que testem hipóteses arriscadas (integração externa, performance, compliance).

Passo a passo: fatiar uma história grande

Cenário: “Como gerente, quero um dashboard de vendas para acompanhar metas.”

1. Identifique decisões que o usuário quer tomar: acompanhar meta mensal? comparar regiões? detectar queda diária?

2. Escolha o menor recorte que já muda uma decisão: “ver total do mês vs meta” pode ser suficiente.

3. Defina uma fatia end-to-end: dados + cálculo + visualização simples + critério de aceitação.

4. Adie variações: filtros avançados, drill-down, exportação, comparativos.

5. Escreva CA para a fatia: fonte de dados, regra de cálculo, atualização, permissões.

Fatia 1 (exemplo):

Como gerente, eu quero ver o total de vendas do mês e a meta do mês, para saber se estamos acima ou abaixo do esperado.

CA (exemplo):

• Dado que estou no dashboard Quando abrir a página Então devo ver total do mês, meta do mês e indicador acima/abaixo.
• Dado que não tenho permissão Quando acessar Então devo ver mensagem de acesso negado.

Refinamento contínuo: manter o backlog pronto para o próximo passo

Refinamento é a prática de revisar e melhorar itens do backlog continuamente: esclarecer, fatiar, adicionar critérios, remover itens obsoletos e reduzir incertezas. O objetivo é ter um conjunto de itens “próximos” em bom estado para serem iniciados sem travas.

Cadência e foco do refinamento

• Curto e frequente: sessões menores tendem a manter o backlog saudável sem virar “reunião infinita”.
• Foco nos próximos itens: refine primeiro o que tem maior chance de entrar em execução em breve.
• Trate incerteza explicitamente: marque hipóteses, dependências e perguntas abertas.

Checklist prático para um item “bem refinado”

• Descrição clara (história ou JTBD) com benefício explícito.
• Escopo mínimo definido (o que entra e o que não entra nesta fatia).
• Critérios de aceitação testáveis.
• Riscos e dependências mapeados (integrações, dados, permissões).
• Tamanho adequado para execução (se estiver grande, fatiar).
• Dados/artefatos de apoio quando necessário (ex.: exemplo de arquivo, regra de cálculo).

Decomposição orientada a valor: do objetivo ao item executável

Decompor orientado a valor significa quebrar trabalho de forma que cada parte entregue um resultado observável para alguém (usuário, operação, compliance, suporte). Isso evita backlogs cheios de tarefas técnicas desconectadas.

Mapa simples de decomposição

Validação rápida com stakeholders: reduzir risco antes de “construir tudo”

Validação rápida é um ciclo curto para confirmar entendimento e valor antes de investir pesado. O foco é obter feedback sobre a fatia mínima: se resolve o problema, se está usável, se atende regras essenciais.

Abordagem prática em 5 passos

1. Prepare um artefato leve: pode ser um protótipo simples, um fluxo desenhado, uma planilha com exemplo de saída, ou uma versão mínima funcionando.

2. Defina perguntas objetivas: “Isso permite tomar a decisão X?”, “O resultado está correto?”, “O que impede o uso no dia a dia?”

3. Rode uma sessão curta de validação (15–30 min): demonstre a fatia e peça para o stakeholder executar um cenário real.

4. Capture feedback como itens acionáveis: transforme em novas histórias, ajustes de CA, ou decisões de escopo (incluindo o que não será feito agora).

5. Atualize o backlog imediatamente: reordene prioridades, refine as próximas fatias e registre aprendizados.

Modelo de roteiro de validação (para usar em reuniões)

• Cenário: “Mostraremos a fatia X para suportar a decisão Y.”
• O que será validado: regras, fluxo, dados, permissões, tempo de resposta (se relevante).
• Critérios de sucesso: “Stakeholder consegue completar tarefa em até N passos”, “dados batem com fonte oficial”, “não há bloqueios críticos”.
• Perguntas finais: “O que está faltando para usar amanhã?”, “O que pode esperar?”, “Qual risco você vê?”

Modelos prontos (copiar e adaptar)

Template de história de usuário (com campos úteis)

Título: [verbo + objeto + contexto]\nHistória: Como [usuário], eu quero [capacidade], para [benefício].\nContexto/Notas: [regras, links, exemplos, hipóteses]\nFora de escopo (nesta fatia): [itens explicitamente adiados]\nCritérios de aceitação (Given/When/Then):\n- ...\nMétricas/telemetria (se aplicável): [o que medir] \nRiscos/Dependências: [integrações, dados, permissões]

Template JTBD

Título: [job em poucas palavras]\nJob: Quando [situação], eu quero [ação/motivação], para que eu possa [resultado].\nSinais de sucesso: [comportamento/métrica] \nRestrições: [compliance, prazos, limitações] \nCritérios de aceitação: [Given/When/Then]

Template de critérios de aceitação (checklist)

• Caminho feliz
• Validações de entrada
• Permissões/perfis
• Mensagens de erro
• Regras de negócio (cálculos, limites)
• Integrações (quando aplicável)
• Requisitos não funcionais relevantes (tempo, auditoria, segurança)