Disclaimer 📢:

Há muitas formas de se responder a uma pergunta e na maioria dos casos não há apenas uma única resposta certa, mas optei por escrever este tema dentro deste modelo de perguntas e respostas por ser um modelo bastante objetivo e intuitivo.

A ideia aqui não é fornecer a resposta a todos os problemas que aqui serão expostos, mas sim exibir um caminho que possa ser pesquisado mais detalhadamente, caso o desperte interesse. 

O que é um critério de aceitação?

Critério de aceitação, como o próprio nome sugere, são os critérios que são definidos (comumente dentro de um Work Item) que diz respeito às regras que devem ser cumpridas sobre uma funcionalidade/solução que será desenvolvida pela equipa, para que atenda o requisito de negócio solicitado pelo Product Owner.

Mais um exemplo: Se pensarmos num site de vendas online que possui a funcionalidade de carrinho de compras, um dos critérios de aceitação em relação a esta funcionalidade poderia ser que a soma dos valores dos itens adicionados ao carrinho, deve ser idêntico ao valor total da compra.

 Para que serve?

Ao final do desenvolvimento de um Work Item, os critérios de aceitação são utilizados como parte do roteiro do que precisa ser validado/testado para se concluir que aquele objetivo do Work Item foi cumprido.

Para além disto, os critérios de aceitação permitem que as pessoas envolvidas na implementação estejam todas alinhadas em relação ao que deve ser desenvolvido e entregue relativamente ao Work Item.

E que problema isso resolve?

• Quando não há critérios de aceitação objetivos e específicos, há vários riscos a serem levados em consideração:
• Tempo de desenvolvimento mais elevado, dado que pode haver muitas dúvidas a pairar no ar o que gera também um desgaste desnecessário na equipa
• Alterações frequentes do mesmo Work Item durante seu desenvolvimento, isso porque se não ficou claro o caminho a ser seguido com os critérios de aceitação, pode-se descobrir a meio do caminho que um fluxo ou outro não faz muito sentido e que é preciso repensá-lo, mudando assim o âmbito do Work Item
• E o pior deles (na minha concepção ), que é descobrir ao final do desenvolvimento que não era bem aquilo que era para ser feito.
• Entre outros.

Quem é o responsável pela definição do critério de aceitação?

O responsável pela definição e escrita dos critérios de aceitação é o Product Owner.

Em algumas equipas que já participei ao longo dos últimos anos, notei que por vezes há uma pessoa a desempenhar uma role ao lado do Product Owner, normalmente conhecido como Business Analyst/Agile Analyst ao qual o Product Owner delega algumas funções.

Mesmo que não seja o Product Owner a escrever os critérios, ainda assim ele é o responsável pelo que lá está escrito.

Além disso, os integrantes da equipa também podem contribuir junto/alinhado ao Product Owner para complementar, sugerir, contribuir com algo que se possa estar a faltar.

Em que momento os critérios são escritos?

Quando se está a fazer uso do Scrum, por exemplo, antes da sessão de refinamento do backlog, o Product Owner escreve e detalha os Work Items, com a informação toda que possui na altura, já com os critérios de aceitação, que serão levados a sessão para serem discutidos/rediscutidos para se então encontrar uma solução ideal em conjunto para o problema que se está a tentar resolver com aquela funcionalidade/necessidade.

Neste momento é super importante que todos estejam esclarecidos sobre o que se pretende com cada critério de aceitação

E quantos critérios um Work Item deve ter?

Não há uma regra de x critérios para cada Work Item.

O que se deve ter em atenção é que, quando temos um Work Item com muitos critérios de aceitação e este pode ser partido em Work Items que continuam a entregar valor, parte-se então (técnica para dividir Work Items em mais Work Items de menores tamanho e menor complexidade).

No próximo episódio XD partilharei um pouquinho mais sobre Definição de Pronto (definition of done) e quais as diferenças deste com os critérios de aceitação.

Valeu pela leitura.