Como podemos garantir que uma história de usuário seja concluída corretamente e atenda aos requisitos do cliente? É aqui quecritérios de aceitação entram em ação. Os critérios de aceitação são uma lista formal de requisitos que garantem que todas as histórias de usuário sejam concluídas e todos os cenários sejam considerados. Em resumo, os critérios de aceitação definem as condições sob as quais uma história de usuário é considerada completa. Critérios claros e escritos ajudam as equipes de desenvolvimento a evitar ambiguidades sobre as necessidades do cliente e a prevenir mal-entendidos.
Portanto, ao escrever histórias de usuário, os critérios de aceitação são essenciais. Eles ajudam sua equipe a entender o que é obrigatório durante o desenvolvimento de recursos e em que deve se concentrar.
Vamos mergulhar nos critérios de aceitação.
O que são Critérios de Aceitação?
Os critérios de aceitação permitem definir quando uma história de usuário está completa e quando possui todos os recursos necessários para satisfazer as necessidades do usuário.
São um conjunto de condições que uma história de usuário deve atender para ser considerada completa. Eles fornecem o escopo detalhado da história de usuário e o que é necessário, para que sua equipe entenda o problema em questão. Dessa forma, toda vez que lançar um novo recurso, poderá garantir que atenda ao padrão que o usuário merece.
Mas antes de listar entusiasticamente um conjunto de critérios funcionais que sua história de usuário deverá atender, considere como outras variáveis podem afetar a qualidade do seu recurso e inclua-as em seus critérios de aceitação.
Os Critérios de Aceitação Podem Incluir Detalhes Como
- Experiência do usuário
- Impacto da história de usuário atual sobre os recursos existentes
- Desempenho-chave, como velocidade
- O que a história de usuário tem como objetivo fazer
Assim, dependendo da funcionalidade que você está construindo e de sua complexidade, sente-se com sua equipe para determinar o subconjunto mínimo de funcionalidades que ela deve realizar e como ela deve se comportar.
Se for complexo ou um recurso central do seu produto, você deveria considerar escrever tantos e tão detalhados critérios de aceitação quanto possível para ajudar sua equipe a evitar qualquer confusão.
Como Escrever Critérios de Aceitação para Histórias de Usuários
1. Os Critérios de Aceitação Devem Ser Escritos do Ponto de Vista do Usuário
Os critérios de aceitação são uma forma de visualizar o problema do ponto de vista do cliente. Devem ser escritos no contexto de uma experiência real do usuário. Afinal, você está construindo um produto para usuários, não é?
2. Os Critérios Devem Ser Claros e Concisos
Os critérios de aceitação não devem ser confundidos com casos de teste ou documentação. É importante manter seus critérios o mais simples e claros possível.
3. Todos Devem Entender Seus Critérios de Aceitação
Se seus desenvolvedores não conseguirem entendê-los, seus critérios são inúteis. Se você tiver dúvidas sobre clareza, dedique tempo para fazer perguntas e ajustar até que tudo fique claro.
4. Os Critérios de Aceitação Não São Sobre Como (Como?). São Sobre O Que (Por Que?)
Como as histórias de usuário, os critérios de aceitação não são tarefas. São uma forma de comunicar a história do usuário.
5. Os Critérios de Aceitação São Específicos, Mas Não São Outro Nível de Detalhe
Considere um software de declaração de impostos. O requisito mais importante é calcular corretamente o imposto devido com base na renda e nas despesas. Claro, certo? E você sabe que não pode testar todas as combinações possíveis — porque as possibilidades são quase infinitas.
Portanto, seus critérios de aceitação para a história de usuário especificarão condições ou requisitos específicos que devem ser atendidos. Isso significa ser mais específico, e não adicionar outra camada de detalhe. Isso ajuda sua equipe a entender o que é necessário e acelera a entrega. É claro que, ao comparar seu gráfico atual de burn-down com os anteriores, você pode perceber algumas melhorias.
6. Os Critérios de Aceitação Podem Ser uma Reformulação da História de Usuário do Ponto de Vista do Usuário
Isso se aplica apenas quando a história do usuário não for excessivamente complexa. Aqui está um exemplo do que quero dizer.
Para uma história de usuário como “Como funcionário financeiro, quero aceitar faturas para que eu possa acompanhar todos os relatórios financeiros”
Seus critérios de aceitação podem ser “Quando eu realizar a ação de aceitar, a fatura será aceita (verificado verificando o registro da fatura)”
Dado/Quando/Então Modelo de Critérios de Aceitação
Para facilitar a vida, aqui está um modelo simples que você pode usar para escrever critérios de aceitação:
Dado [contexto] quando [uma ação específica for realizada] então [um conjunto de consequências deverá ocorrer]
Exemplos de Critérios de Aceitação
Para a história de usuário de exemplo:
“Como escritor, quero receber notificações quando outros adicionarem comentários para que eu possa me manter atualizado.”
Aqui estão três exemplos de critérios de aceitação para a história de usuário acima:
- Dado meu telefone está bloqueado quando o aplicativo não está aberto, então eu devo receber uma notificação em banner.
- Dado estou escrevendo um documento quando o aplicativo está aberto, então o ícone do sino deve ser atualizado para mostrar notificações não lidas com uma contagem.
Exemplo – Envio de Feedback do Site
Especificamos a história do usuário e os critérios de aceitação para o recurso de comentários do blog. Usuários logados podem adicionar comentários. A história do usuário para o recurso “Adicionar Comentário” seria:
Como um usuário logado,
Eu quero poder deixar um comentário em uma publicação de blog,
para queeu possa receber feedback sobre o tema.
Os critérios de aceitação para este recurso são:
Cenário: Um usuário logado deixa um comentário em uma publicação de blog
Dado que sou um usuário logado,
Quando abro a página que contém uma publicação de blog específica,
Então o sistema exibe uma seção de “Comentários” abaixo da publicação de blog, mostrando uma lista de comentários adicionados por outros usuários.
O sistema exibe um campo de “Adicionar Comentário” no topo da seção de “Comentários”.
Quando preencho o campo de “Adicionar Comentário” com meu comentário e clico no botão “Enviar”,
Então o sistema salva meu comentário.
O sistema exibe meu comentário no topo da seção de “Comentários”.
O sistema exibe meu nome de usuário e meu avatar à esquerda do meu comentário.
O sistema exibe ícones de “Excluir” e “Editar” no lado oposto do meu comentário.
Como você pode ver, escrever critérios de aceitação é verdadeiramente um ganha-ganha para clientes e equipes de desenvolvimento: não apenas ajuda a equipe a entender claramente o que precisa ser feito, mas também permite que os clientes compreendam o processo de desenvolvimento e verifiquem se o software entregue atende às necessidades reais do negócio.
- Histórias de Usuário Efetivas – Guia dos 3C e INVEST
- Desenvolvimento Ágil – Iterativo e Incremental
- O que é o Product Backlog no Scrum? Quem é responsável por ele?
- Como refinar o Product Backlog?
- O que é o Sprint Backlog no Scrum?
- Como priorizar o Product Backlog usando o método MoSCoW
- Como priorizar o Product Backlog usando o método dos 100 pontos?
- O que é um Objetivo de Sprint no Scrum?
- O que é o Gráfico de BurnDown no Scrum?
- O que é o modelo de Papel-Funcionalidade-Razão?
- Incremento de Sprint vs Produto Potencialmente Entregável vs MVP vs MMP
- Escreva Metas SMART e INVEST para Histórias de Usuários