Come faccio a spiegare alla mia squadra "non c'è alcun problema se i requisiti devono cambiare dopo uno sprint?"

Ci possono essere molte parti interessate nel mondo reale, ma per quanto riguarda gli sviluppatori, ce n'è solo una: il product manager che è stato selezionato dalle aziende coinvolte per avere la responsabilità che il prodotto creato è ciò di cui le parti interessate hanno bisogno . Se quella persona non è lì o non riesce a fare il proprio lavoro, il progetto fallirà.

Il product manager crea singole attività che sono realizzabili e hanno un criterio di accettazione e le priorità. Il team decide quali compiti svolgeranno durante uno sprint, sulla base di stime ragionevoli per la durata delle attività, tenendo conto delle priorità e delle dipendenze. E poi il team fa del suo meglio per svolgere questi compiti durante uno sprint.

Ora se il product manager cambia idea e il lavoro svolto nello sprint richiesto risulta inutile, il team di sviluppo non deve preoccuparsi nel senso che non è colpa loro. È ancora una perdita di tempo che influenzerà il progetto.

Il coinvolgimento di uno stakeholder primario (il "rappresentante del cliente") sarà richiesto per fare in modo che questo funzioni. Ecco perché:

1. I requisiti devono essere accompagnati da un test di accettazione che, una volta eseguito, dimostra inequivocabilmente che il requisito è stato soddisfatto. Se non è accompagnato da un test di accettazione, non è un requisito; è un desiderio.

2. Se stai facendo questo in modo "agile", hai solo tempo per circa sei sprint per l'intero progetto. Senza un feedback ravvicinato e continuo da parte del cliente, non è possibile farlo.

3. Quasi certamente stai sottovalutando la portata del lavoro. Due mesi non sono un sacco di tempo. Il tuo ultimo paragrafo, "non c'è alcun problema se i requisiti devono cambiare dopo uno sprint" praticamente garantisce che non verrà eseguito in 2 mesi.

4. Se un requisito cambia a causa del coinvolgimento degli stakeholder, devi ottenere l'approvazione per estendere il tempo necessario al completamento.

Hai detto che stai usando Sprint, il che mi permette di presumere che stai implementando un approccio Agile come Scrum. In questo caso, dovresti avere un Product Owner (PO) che lavora con il team per chiarire eventuali domande che potrebbero avere il tempo, durante la pianificazione dello sprint e durante lo sprint. Lo scopo del ruolo di PO è di mantenere i contatti con lo stakeholder / cliente e il team. In nessun caso il team deve fare supposizioni o deiezioni su ciò che il cliente vorrà.

Se hai un PO in atto, allora l'OP è l'unico che può prendere queste decisioni per il team e dovrebbe dare la priorità a tali decisioni di conseguenza.

In secondo luogo, quando si esegue la pianificazione sprint, è importante concordare un obiettivo di sprint, con l'input dal PO e dal team - questo aiuta a mantenere il team focalizzato su ciò che è importante e aiuta a impedire che il team vada fuori su una tangente.

Infine, l'obiettivo dello sprint può influenzare il modo in cui le storie vengono suddivise e, se si fatica a tenere il team focalizzato, dedicare più tempo alla suddivisione delle storie in attività secondarie per garantire che sia il team che l'OP si trovino sulla stessa pagina. Puoi quindi incoraggiare il team a concentrarsi solo sul lavoro su queste attività secondarie