Diferença entre critério de aceitação, definição de pronto e definição de pronto pronto

Há uma semana atrás estava participando de uma sprint review e um dos itens do sprint backlog não foi entregue. Porque ocorreu isso neste momento depois de alguns sprints? Observando a conversa da equipe consegui observar que faltou clareza em relação ao critério de aceitação ou teste de aceitação do item do backlog.

Parece óbvio que todo item do backlog do produto precisa ter um critério de aceitação para que não ocorra discordância se aquilo foi entregue ou não. Isso me fez voltar no Scrum Guide para ver se critério de aceitação ou testes de aceitação estavam descritos.

O que o Scrum Guide fala é que um item do backlog ou PBI deve ter quatro atributos: descrição, ordenação, estimativa e valor para o negócio. Está descrito que geralmente o teste de aceitação será um atributo. Para que a equipe de desenvolvimento tenha certeza que todos os atributos necessários estejam presentes ela pode incluir isso dentro do definition of ready. A “definition of ready” definição de preparado onde a equipe de scrum define as informações mínimas necessárias para que um item do backlog possa ser elegível para ser discutido em uma próxima sprint planning.

Lendo e pesquisando um pouco mais a fundo consegui identificar que a prática de ter critérios de aceitação acabou surgindo em conjunto com o uso de criação de histórias de usuários para definição de requisitos. Na verdade, a expressão utilizada pelo Mike Cohn em seu livro “Applying user stories”, “teste de aceitação” menciona que as histórias de usuários precisam ter os critérios de teste definidos pelo cliente — isso mesmo pelos clientes antes do início do desenvolvimento. Isso traz uma melhor prática do XP (Extreme programming), de TDD (desenvolvimento orientado a teste). Fazendo uso do desenvolvimento orientado a teste, o teste inicialmente falha. Ele falha porque o desenvolvimento não foi feito ainda seguindo os critérios de sucesso. Após o desenvolvimento, se os critérios forem seguidos, o teste passa. Neste caso temos o cenário vermelho (falha) no primeiro caso e depois verde (sucesso) no segundo. Essa abordagem é mais conhecida como “red green refactor” entre os desenvolvedores. Logo ter o acceptance test ou critério de aceitação acaba virando um dos atributos adicionais em cada item do backlog.

Mas então para que serve a definição de pronto (DOD)? Ele traz atributos que todas as histórias precisam atender para que sejam entendidos como pronto durante o sprint. Um exemplo é critérios de segurança que todos os desenvolvimentos da sua empresa precisam ter e testes de segurança que eles precisam passar. Ele traz requisitos genéricos aplicáveis a todos os itens do backlog que integram o produto funcional ao do sprint. O DOD no decorrer dos sprints começa a incluir novos atributos identificados durante as entregas dos sprints. Geralmente eles florescem para impedir que novos débitos técnicos sejam criados.

E que raios é o DODD — definição de feito feito? Esta terminologia não existe. Ela deve ser alguma disfunção da equipe que não incluiu todos os requisitos de feito e não tem um incremento de produto utilizável ao término do sprint. Não podemos ter duas definições de pronto uma para equipe e outra para o cliente.

Equipe do scrum deve durante a sprint review entender os requisitos da definição de feito e alinhar os atributos necessários que fazem parte para evitar ter incrementos que aparentemente foram entregues mas não são utilizáveis. Neste caso teremos o falso feito que pode dar origem ao feito feito ou feito de verdade.

Voltar