Il proprietario del prodotto introduce User Story non classificate (non familiari, non stimate) nella riunione di Sprint Planning

Dato che hanno appena ricevuto la storia durante la pianificazione (indipendentemente dal fatto che si tratti di una nuova storia o di non averla prima valutata), hai alcune scelte.

In primo luogo, puoi chiedere al proprietario del prodotto se la storia può essere lasciata nel backlog in modo che possa essere correttamente controllata e valutata durante lo sprint e portarla allo sprint successivo.

Se ciò non è possibile, un'altra opzione è quella di farlo in uno spike, una storia in time-box per indagare su qualcosa o provare qualcosa - e poi avresti un vantaggio per il prossimo sprint.

Infine, se davvero devi iniziare con questo sprint, cerca di scoprire il più possibile durante la pianificazione e prendi la storia, ma chiarisci il rischio che non possa essere completato questo sprint. Se non viene completato, così sia, ne hai fatto un po 'e ora ne sai molto di più per il prossimo sprint.

Ricorda che le stime sono solo le migliori stime con le informazioni che hai in quel momento e possono essere riviste in seguito quando avrai maggiori informazioni.

Ricorda inoltre che dovresti spendere circa il 5% -10% dello sprint per rifinire il backlog. Ciò aiuta a mantenere gli incontri di pianificazione più brevi, più mirati e più produttivi.

La stima non è qualcosa che dovrebbe essere fatto a mano o in modo rapido e senza pensieri, indipendentemente dalla metodologia. Non mi aspetto che il team sia in grado di elaborare rapidamente una stima ragionevole senza avere l'opportunità di guardare la user story e pensarci per un po '. Allo stesso tempo, riconosco che ci sono nuove funzionalità ad alta priorità, correzioni di bug o modifiche alle funzionalità che devono essere risolte rapidamente in modo che il cliente possa vedere un valore aggiunto. È un compromesso tra la distribuzione della funzionalità ora rispetto al mantenimento della pianificazione e / o della qualità che deve essere discussa.

Se questa è una cosa continua, ciò suggerisce un problema con il processo. Ciò non significa che il processo non funzioni, ma piuttosto (in questo caso) il Product Owner non comprende il valore nel processo. Il Product Owner e il resto del team di Scrum devono essere in grado di lavorare insieme. Continuare a sacrificare la pianificazione o la qualità non è di buon auspicio per il progetto. Ad un certo punto, credo che ScrumMaster, a nome del team, debba tracciare una linea e semplicemente inserire la storia nel backlog per la stima in un secondo momento e non includerla nello sprint. Sarà solo in cima all'arretrato per il prossimo. Ciò ridurrà lo stress e consentirà una maggiore qualità.

Uno strumento utile in questa situazione è Pianificazione del poker . Il team impiega alcuni minuti a porre domande al proprietario del prodotto sulla storia e quindi stimano ciascuno i punti della storia. La varietà di stime viene utilizzata per sondare le lacune. Utilizzando questo strumento nel tempo, l'OP inizierà a capire quali domande devono essere risolte prima di pianificare.

L'Agile Project Manager (Scrum Master) dovrebbe lavorare a stretto contatto con il Product Owner per sviluppare storie di dimensioni chiaramente definite appropriate. Il PM dovrebbe proteggere gli sviluppatori dal dover stimare storie incomplete e gli sviluppatori non dovrebbero impegnarsi in una storia che non è possibile raggiungere mai.