Dato che stai usando Agile, ci si aspetta che tu abbia una versione funzionante a intervalli regolari. Gli intervalli dipendono dal tuo approccio preciso: può durare un paio di settimane (la durata dei tuoi sprint) o anche pochi minuti se usi integrazione continua .
Avere costantemente una versione funzionante rende facile per i tuoi stakeholder testare se stessi sul prodotto. Allo stesso modo, è facile fare una demo ai tuoi stakeholder se lo desiderano.
Il fatto che il progetto non vada sempre avanti non cambia nulla: la demo viene eseguita su un prodotto funzionante in un dato periodo di tempo, non sul progresso. Se i tuoi stakeholder vogliono vedere il progresso , per esempio, per avere una chiara idea di cosa è stato fatto dall'ultimo sprint, non dovrebbero chiedere una demo, ma piuttosto vai a vedere il backlog .
Di solito è meglio fare le dimostrazioni non a intervalli regolari, ma quando rilasci una funzione importante. Effettuare una demo dopo aver trascorso due settimane a fare importanti refactoring darà una cattiva impressione agli stakeholder, il che potrebbe riflettere il loro atteggiamento nei confronti del refactoring, i metodi Agile, la tua squadra, la tua credibilità, ecc.
Ricorda che Agile incoraggia un'interazione quasi costante tra il team e gli stakeholder , in particolare per ottenere rapidamente feedback su ciò che è stato fatto e su ciò che dovrebbe essere fatto presto. Se questa interazione viene eseguita correttamente, le parti interessate sono già ben informate sullo stato attuale del prodotto, le caratteristiche e il progresso. Ciò rende le dimostrazioni molto meno utili rispetto ai progetti Waterfall, in cui il cliente può rimanere cieco durante lo sviluppo e scopre il progetto mesi dopo.