Guia Scrum | 22. Critérios de aceitação da história do usuário

User Story é uma técnica que permite que as empresas entreguem produtos e serviços que atendam ao máximo às necessidades do cliente. Os critérios de aceitação da história do usuário aprimoram a avaliação das novas funcionalidades do produto do ponto de vista do usuário.

Critérios de aceitação da história do usuário - índice:

1. Introdução
2. Como formular os Critérios de Aceitação da História de Usuário?
3. Critérios de aceitação da história do usuário versus definição de concluído
4. Resumo

Introdução

Cobrimos a história do usuário e os problemas a serem resolvidos na sua criação em artigos anteriores. Hoje, no entanto, vamos nos concentrar nos critérios de aceitação da história do usuário.

Os critérios de aceitação devem seguir estas diretrizes:

• descrever a funcionalidade nova e aprimorada do Produto do ponto de vista do usuário
• ser único para cada história de usuário

O Guia oficial do Scrum não define a História do Usuário e seus critérios de aceitação. Eles são opcionais, mas elementos muito comuns do trabalho Scrum. Ainda assim, para aliviar a curiosidade de nossos leitores, vamos descrevê-los como: As condições que um aprimoramento de Produto deve atender durante um determinado Sprint para obter a aprovação do Usuário.

Como formular os Critérios de Aceitação da História de Usuário?

Uma História de Usuário bem escrita contém uma descrição clara do contexto ou situação a que se refere, atendendo assim aos critérios de aceitação. Ainda assim, é apenas uma frase curta, muito vaga e ambígua para apontar diretamente as considerações necessárias.

Clareza e acessibilidade dos critérios de aceitação

Portanto, para evitar ambiguidades, realize e grave uma conversa detalhada com o cliente para determinar o objetivo da solução implementada. Lembre-se que a formulação final dos critérios de aceitação pertence ao Product Owner.

Anote-os junto com os critérios da história do usuário antes do planejamento da sprint. Cada membro do Time Scrum deve lê-lo e confirmar que entende e concorda com os critérios de aceitação da História do Usuário. Normalmente, os critérios de aceitação estão do outro lado do cartão da história do usuário.

Critérios de aceitação adequadamente formulados permitem que o usuário verifique se o teste da História do Usuário segue sua descrição. Os critérios podem assumir a forma de uma lista de verificação com marcadores para marcar quando concluídos durante o teste do produto no final de um Sprint.

A questão é simples se a operação do Produto for transparente para o Usuário. No entanto, quanto mais complexo o produto, mais difícil fica para testar. Pegue software complexo ou serviços de grande escala. Portanto, na maioria dos casos, uma ferramenta útil para validar a User Story é preparar um teste de aceitação.

Teste de aceitação

Se você decidir desenvolver um teste de aceitação, coloque-o no outro lado do cartão que contém a história do usuário. Mais tarde, o Time Scrum ou um time externo de QA pode realizá-lo.

O teste deve, em primeiro lugar, conter uma declaração clara sobre se o Produto é reprovado ou aprovado no teste. Não pode conter declarações de porcentagem ou avaliação intermediária.

Se a história do usuário tiver mais de um critério de aceitação, cada um exigirá testes separados. Dessa forma, é muito mais fácil determinar qual funcionalidade do produto precisa ser aprimorada ou refinada e é especialmente importante se as novas funcionalidades incluídas na história do usuário se sobrepuserem ou forem independentes umas das outras.

Critérios de aceitação da história do usuário versus definição de concluído

Definição de Pronto é parte integrante do trabalho em Scrum, que é o equivalente técnico dos critérios de aceitação. No entanto, você não deve confundir esses dois, pois denotam compromissos diferentes. O que é a Definição de Pronto, e como e quando formulá-la é uma questão que abordamos em um post separado?

Aqui, mencionaremos apenas que a Definição de Pronto é uma descrição clara e transparente do estado esperado do Produto após a conclusão do Incremento no Backlog do Produto. Descreve as melhorias feitas no Incremento. Isso contrasta com o critério de aceitação correspondente à História do Usuário, que descreve a funcionalidade do Produto criada durante o último Sprint conforme é percebida pelo Cliente.

Por exemplo, pegue esta história de usuário com o conteúdo:

Como cliente logado de uma loja online, quero comprar uma varinha mágica com um clique.

A Definição de Conclusão para a História de Usuário acima pode incluir o seguinte:

• a criação de um painel de login para clientes da loja
• integração do sistema de pagamento
• adicionando o botão de pagamento instantâneo ao modelo de página do produto

Por outro lado, os critérios de aceitação do cliente apresentam:

• a capacidade de fazer login na loja
• a possibilidade de definir um método de pagamento padrão
• botão de trabalho "Comprar agora" para o produto "varinha mágica"

Resumo

Os critérios de aceitação são um conjunto de condições que funcionam como forma de avaliar a implementação da User Story. Ao descrever o desempenho do produto novo e aprimorado do ponto de vista do usuário, esse método se torna uma ferramenta eficaz para trabalhar com o cliente. Apresenta o desempenho do Time Scrum do ponto de vista do usuário.

Critérios de aceitação bem formulados, por exemplo na forma de um teste de aceitação, também nos permitem verificar durante um Sprint se a funcionalidade criada melhora o atendimento às demandas do Cliente.

Os critérios de aceitação diferem da Definição de Pronto principalmente na perspectiva que assumem na expressão. Eles não contêm uma descrição dos requisitos técnicos que a nova solução deve atender, mas apenas as funções que o produto deve apresentar após a atualização da nova User Story.

Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Ver todas as postagens

Guia do Scrum:

1. Glossário de termos básicos, funções e noções
2. O que é Scrum?
3. Valores do Scrum
4. Como implementar o Scrum na sua empresa?
5. Time Scrum - o que é e como funciona?
6. Quem é um Product Owner?
7. Os erros mais comuns do Product Owner
8. Quem é o Scrum Master?
9. Características de um bom Scrum Master
10. Os erros mais comuns do Scrum Master
11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
12. Cooperação entre Product Owner e Scrum Master
13. Equipe de Desenvolvimento em Scrum
14. Os erros mais comuns dos desenvolvedores
15. Artefatos do Scrum
16. Escalando Scrum
17. Backlog da Sprint
18. O que é o Backlog do Produto?
19. O que são histórias de usuários?
20. Criando a melhor história de usuário com INVEST
21. Os erros mais comuns da história do usuário
22. Critérios de aceitação da história do usuário
23. Estimativa e pontos de história no Scrum
24. Poker de Planejamento
25. Jogo de estimativa de equipe
26. Definindo Incremento
27. Eventos Scrum
28. O que é Sprint no Scrum?
29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
30. O que é um gráfico Burndown?
31. Como criar e interpretar um gráfico de burndown?
32. Vantagens e desvantagens do gráfico de burndown
33. Quadros Kanban em Scrum e Scrumban
34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
35. Reunião diária
36. Planejamento de Sprint
37. Revisão da Sprint
38. O que é uma Sprint Retrospective?
39. Erros comuns durante uma Sprint Retrospective
40. Nutrição do Backlog do Produto