Os critérios de aceitação podem ser escritos após o início do sprint?

Vamos entender a necessidade de um critério de aceitação. Essencialmente, um critério de aceitação descreve as restrições externas sob as quais uma dada funcionalidade do sistema deve operar (e potencialmente coexistir com restrições impostas a outros requisitos em outras partes do sistema). Por sua vez, eles servem duas funções críticas para que a equipe de engenharia -

(a) projete e desenvolva o sistema mantendo essas restrições em mente (o que significa tanto projetar os algoritmos e estruturas de dados, quanto prover uma quantidade adequada de recursos do sistema no desempenho mais econômico possível para um determinado sistema), e

(b) para validar que o sistema realmente atende a essas restrições (o que significa quando o critério de saída tiver sido atendido, a equipa pode parar de validar o software e preparar-se para o lançamento / lançamento)

Needless para dizer, quanto mais rigorosos e abrangentes forem os critérios de aceitação, mais esforço seria necessário para a equipa de engenharia entregar "software de trabalho" no final do sprint, que inclui não só os requisitos funcionais mas também os critérios de aceitação associados (que muitas vezes levam a requisitos não funcionais que requerem esforços adicionais por parte da equipa). Se estes não forem conhecidos previamente, a equipa poderá ser forçada a fazer suposições unilaterais sobre os limites do sistema no momento do planeamento do sprint. No entanto, se os critérios de aceitação só forem explicitamente declarados mais tarde quando o sprint estiver a decorrer, a equipa pode ser forçada a alterar a sua arquitectura ou o desenho, o que pode ter um efeito em cascata no desenvolvimento e esforço de teste, pondo assim em risco os compromissos originais assumidos no início do sprint. Além disso, pode também ter um efeito psicológico sobre a equipa - a equipa pode sempre viver sob o medo constante de que uma mudança mais tarde possa vir a qualquer momento e forçá-los a alterar o seu design e os seus planos. No entanto, se estes forem conhecidos de antemão, a equipa sabe como melhor desenhar o sistema e apresentar os seus planos de melhor esforço para os entregar em conformidade.