A User Story é uma técnica que permite que as empresas entreguem produtos e serviços que atendam às necessidades dos clientes ao máximo. Os critérios de aceitação da User Story aprimoram a avaliação das novas funcionalidades do Produto do ponto de vista do usuário.
Critérios de Aceitação da User Story – índice:
- Introdução
- Como formular os Critérios de Aceitação da User Story?
- Critérios de Aceitação da User Story vs. Definição de Pronto
- Resumo
Introdução
Abordamos a User Story e as questões a serem tratadas em sua criação em artigos anteriores. Hoje, no entanto, focaremos nos critérios de aceitação da User Story.
Os critérios de aceitação devem seguir estas diretrizes:
- descrever a nova e melhorada funcionalidade do Produto do ponto de vista do usuário
- ser únicos para cada User Story
O Guia Oficial do Scrum não define a User Story e seus critérios de aceitação. Eles são opcionais, mas elementos muito comuns do trabalho em Scrum. Ainda assim, para satisfazer a curiosidade de nossos leitores, os descreveremos como: As condições que uma melhoria do Produto deve atender durante um determinado Sprint para obter aprovação do Usuário.
Como formular os Critérios de Aceitação da User Story?
Uma User Story 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. No entanto, é apenas uma frase curta, muito vaga e ambígua para identificar diretamente as considerações necessárias.
Clareza e acessibilidade dos critérios de aceitação
Portanto, para evitar ambiguidades, conduza e registre uma conversa detalhada com o cliente para determinar o propósito da solução implementada. Lembre-se de que a formulação final dos critérios de aceitação pertence ao Product Owner.
Anote-os junto com os critérios da User Story antes do Planejamento do Sprint. Cada membro da equipe Scrum deve lê-los e confirmar que entende e concorda com os critérios de aceitação da User Story. Normalmente, os critérios de aceitação estão do outro lado do cartão da User Story.
Critérios de aceitação formulados corretamente permitem que o usuário verifique se o teste da User Story segue sua descrição. Os critérios podem assumir a forma de uma lista de verificação com itens a serem marcados quando concluídos durante o teste do Produto no final de um Sprint.
A questão é simples se o funcionamento do Produto for transparente para o Usuário. No entanto, quanto mais complexo o produto, mais difícil se torna o teste. Considere softwares complexos ou serviços em 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 do outro lado do cartão contendo a User Story. Mais tarde, a equipe Scrum ou uma equipe de QA externa pode realizá-lo.
O teste deve conter, acima de tudo, uma declaração clara de se o Produto falha ou passa no teste. Não pode conter declarações percentuais ou avaliações intermediárias.
Se a User Story tiver mais de um critério de aceitação, cada um requer testes separados. Dessa forma, é muito mais fácil determinar qual funcionalidade do produto precisa de melhorias ou refinamentos e isso é especialmente importante se novas funcionalidades incluídas na User Story se sobrepuserem ou forem independentes umas das outras.
Critérios de Aceitação da User Story vs. Definição de Pronto
A Definição de Pronto é uma parte integral 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 eles 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 Product Backlog. Ela descreve as melhorias feitas dentro do Incremento. Isso contrasta com o critério de aceitação correspondente à User Story, que descreve a funcionalidade do Produto criada durante o último Sprint, conforme percebido pelo Cliente.
Por exemplo, considere esta User Story com o conteúdo:
Como um cliente logado de uma loja online, quero comprar uma varinha mágica com um clique.
A Definição de Conclusão para a User Story acima pode incluir o seguinte:
- a criação de um painel de login para os clientes da loja
- integração do sistema de pagamento
- adição do botão de pagamento instantâneo ao modelo da 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 “Comprar agora” funcionando para o produto “varinha mágica”
Resumo
Os critérios de aceitação são um conjunto de condições que funcionam como uma forma de avaliar a implementação da User Story. Ao descrever o desempenho novo e melhorado do Produto do ponto de vista do usuário, esse método se torna uma ferramenta eficaz para trabalhar com o Cliente. Ele apresenta o desempenho da equipe 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 adotam ao serem expressos. 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 concretizaçã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.
Caroline Becker
Como Gerente de Projetos, Caroline é uma 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 a tornam a melhor pessoa para transformar projetos complicados em realidade.
Scrum Guide:
- Glossário de termos básicos, papéis e noções
- O que é Scrum?
- Valores do Scrum
- Como implementar o Scrum na sua empresa?
- Equipe Scrum - o que é e como funciona?
- Quem é um Product Owner?
- Os erros mais comuns do Product Owner
- Quem é o Scrum Master?
- Os erros mais comuns do Scrum Master
- Quais estatísticas e métricas o Scrum Master deve acompanhar?
- Equipe de Desenvolvimento em Scrum
- Os erros mais comuns dos desenvolvedores
- Artefatos do Scrum
- Escalando o Scrum
- Backlog da Sprint
- O que é o Product Backlog?
- O que são Histórias de Usuário?
- Criando a melhor User Story com INVEST
- Os erros mais comuns em User Stories
- Critérios de Aceitação da História do Usuário
- Estimativa e Pontos de História no Scrum
- Planning Poker
- Jogo de Estimativa da Equipe
- Definindo Incremento
- Eventos Scrum
- O que é um Gráfico de Queima?
- Vantagens e desvantagens do gráfico de burndown
- Quadros Kanban no Scrum e Scrumban
- Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
- Scrum Diário
- Planejamento de Sprint
- Revisão da Sprint
- O que é uma Retrospectiva de Sprint?
- Erros comuns durante uma Retrospectiva de Sprint
- Cuidado do Product Backlog
- Como criar e interpretar um gráfico de burndown?