I criteri di accettazione possono essere scritti dopo l'inizio dello sprint?

Comprendiamo la necessità di un criterio di accettazione. Essenzialmente, un criterio di accettazione descrive i vincoli esterni sotto i quali una data funzionalità del sistema deve operare (e potenzialmente coesistere con i vincoli imposti da altri requisiti altrove nel sistema). A loro volta, servono due funzioni critiche per il team di ingegneri -

(a) progettare e sviluppare il sistema tenendo a mente quei vincoli (il che significa sia progettare gli algoritmi e le strutture dati, sia prevedere una quantità adeguata di risorse di sistema nella performance più economica possibile per un dato sistema), e

(b) validare che il sistema soddisfi effettivamente quei vincoli (il che significa che quando il criterio di uscita è stato soddisfatto, il team può smettere di convalidare il software e prepararsi per il lancio/rilascio)

Inutile dire che più i criteri di accettazione sono rigorosi e completi, più sforzo richiederà il team di ingegneri per consegnare un "software funzionante" alla fine dello sprint, che non solo include i requisiti funzionali ma anche i criteri di accettazione associati (che spesso portano a requisiti non funzionali che richiedono sforzi aggiuntivi da parte del team). Se questi non sono noti in anticipo, il team potrebbe essere costretto a fare ipotesi unilaterali sui confini del sistema al momento della pianificazione dello sprint. Tuttavia, se i criteri di accettazione sono dichiarati esplicitamente solo dopo, quando lo sprint è in corso, il team potrebbe essere costretto a modificare la propria architettura o il design, e questo potrebbe avere un effetto a cascata sullo sforzo di sviluppo e di test, mettendo così a rischio gli impegni originali presi all'inizio dello sprint. Inoltre, potrebbe anche avere un effetto psicologico sul team - il team potrebbe vivere sempre sotto la costante paura che un cambiamento successivo potrebbe arrivare in qualsiasi momento e costringerli a modificare il loro design e i loro piani. Tuttavia, se questi sono conosciuti in anticipo, il team sa come progettare al meglio il sistema e presentare i loro piani migliori per consegnarli di conseguenza.