Qual é a diferença entre a história do usuário e os critérios de aceitação?

Table of Contents hide

3.1 Por exemplo, na indústria de software, as equipes podem precisar fazer algumas das seguintes perguntas para chegar ao seu DoD:

4 Critérios de Aceitação

5 Os objetivos dos Critérios de Aceitação

6 Exemplo – Critérios de Aceitação

7 Exemplo de história de usuário com critérios de aceitação

Definição de Pronto (DoD) é uma lista de requisitos que uma história de usuário deve seguir para que a equipe a chame de completa. Enquanto os Critérios de Aceitação de uma História de Usuário consistem em um conjunto de Cenários de Teste que devem ser atendidos para confirmar que o software está funcionando conforme o esperado.

A diferença entre esses dois é que o DoD é comum para todas as User Stories, enquanto os Critérios de Aceitação são aplicáveis a uma User Story específica . Os critérios de aceitação de cada história de usuário serão diferentes com base nos requisitos dessa história de usuário.

Em outras palavras, tanto o DoD quanto os Critérios de Aceitação devem ser atendidos para completar a História do Usuário. O Incremento do Produto não é considerado completo, a menos que essas duas listas sejam feitas. Assim, precisamos definir dois aspectos da Definição de Pronto (DOD) — Critérios de Conclusão e Critérios de Aceitação:

Definição de Pronto

A definição de Pronto está estruturada como uma lista de itens, cada um usado para validar uma História ou PBI, que existe para garantir que a Equipe de Desenvolvimento concorde com a qualidade do trabalho que está tentando produzir. Ele serve como uma lista de verificação que é usada para verificar a integridade de cada Item do Backlog do Produto (também conhecido como PBI) ou História do Usuário. Os itens na definição de “Concluído” devem ser aplicáveis a todos os itens do Product Backlog, não apenas a uma única História de Usuário . Ele pode ser resumido da seguinte forma:

O termo se aplica mais ao incremento do produto como um todo
Na maioria dos casos, o termo implica que o incremento do produto pode ser entregue
O termo é definido no Guia do Scrum
Usado como uma forma de comunicação entre os membros da equipe
Qualidade geral do software
Se o incremento é entregável ou não

Os objetivos da Definição de Pronto

Construir um entendimento comum dentro da equipe sobre qualidade e integridade
Use como uma lista de verificação que as histórias de usuário (ou PBIs) são verificadas
Garantir que o incremento enviado ao final do Sprint tenha alta qualidade e que a qualidade seja bem compreendida por todos os envolvidos.

Exemplo – Definição de Pronto

Por exemplo, na indústria de software, as equipes podem precisar fazer algumas das seguintes perguntas para chegar ao seu DoD:

Código revisado por pares?
Código concluído?
Código revisado?
Código registrado?
Testes unitários passaram?
Testes funcionais passaram?
Testes de aceitação concluídos?
Product Owner revisado e aceito?

Critérios de Aceitação

As histórias de usuário são um dos principais artefatos de desenvolvimento para o desenvolvimento ágil , mas o Scrum não exige explicitamente que as histórias de usuário ou os critérios de aceitação sejam usados. Se um item do backlog do produto for considerado grande demais para ser colocado em um sprint, normalmente será dividido em história de usuário e, posteriormente, em um conjunto de tarefas, conforme mostrado na Figura:

As histórias de usuário encapsulam os critérios de aceitação, portanto, muitas vezes vemos a definição de critérios de aceitação e concluídos coexistindo em nosso processo de desenvolvimento de scrum. A história do usuário fornece o contexto da funcionalidade que a equipe deve entregar. Os critérios de aceitação orientam sobre os detalhes dessa funcionalidade e como o cliente os aceitará. Os dois juntos fornecem toda a entrega.

Alguns dos Critérios de Aceitação serão descobertos em eventos de Refinamento do Backlog Contínuo antes do início do Sprint, e outros serão descobertos logo após o Planejamento do Sprint , quando se sentar para conversar sobre a história do usuário em uma pequena equipe. Portanto, os Critérios de Aceitação são atributos exclusivos da História do Usuário ou do Item do Backlog do Produto.

O termo se aplica a um PBI/História individual
Os Critérios de Aceitação são diferentes para cada PBI/História
O prazo não está definido no Guia do Scrum
Usado como uma forma de comunicar a todos os envolvidos que os requisitos para um PBI/história em particular foram atendidos
Aka Testes de Aceitação, Condições de Satisfação, em alguns casos “Casos de Teste”, etc.

Os objetivos dos Critérios de Aceitação

Esclareça o que a equipe deve construir antes de começar a trabalhar
Garantir que todos tenham um entendimento comum do problema
Ajude os membros da equipe a saber quando a história está completa
Ajude a verificar a história por meio de testes automatizados.

Exemplo – Critérios de Aceitação

Um usuário não pode enviar um formulário sem preencher todos os campos obrigatórios
As informações do formulário são armazenadas no banco de dados de registros
O pagamento pode ser feito via cartão de crédito
Um e-mail de confirmação é enviado ao usuário após o envio do formulário

Exemplo de história de usuário com critérios de aceitação

A figura abaixo mostra um exemplo de critérios de aceitação de uma história de usuário.

Referências