Continua il nostro impegno a rendere fruibili in brevi pillole tutti i preziosi contenuti della Guida SBOK®, tradotta da PME in lingua Italiana per conto di SCRUMstudy, a vantaggio di tutti coloro che vogliono conoscere più a fondo Scrum, e magari anche capire se una certificazione Scrum potrebbe essere loro di aiuto nel percorso di crescita professionale.
L’argomento di oggi è come si passa dalla scrittura e prioritizzazione delle User Story che formano il Prioritized Product Backlog alla realizzazione di incrementi di prodotto o servizio, o più genericamente deliverable, funzionanti, e perciò accettati dal Product Owner e potenzialmente consegnabili al cliente(1).
Il primo passo è la pianificazione dello Sprint. Lo Scrum Team si riunisce negli Sprint Planning Meeting per pianificare il lavoro da portare a termine nello Sprint. Il team rivede le User Story Stimate che si trovano in cima al Prioritized Product Backlog. Il Product Owner partecipa a questa riunione, nel caso siano necessari chiarimenti sulle User Story o sulle priorità. Per aiutare a fare in modo che il gruppo rimanga focalizzato sull‘argomento, questa riunione dovrà avere una durata predeterminata, con la lunghezza standard fissata in due ore per ogni settimana di durata dello Sprint. Questo aiuta a prevenire la tendenza a divagare in discussioni che dovrebbero essere in realtà intavolate in altre riunioni.
Lo Scrum Team prende in carico un sottoinsieme di User Story Stimate del Prioritized Product Backlog che ritiene di poter completare nello Sprint attuale sulla base della propria velocità. Le User Story Prese in Carico verranno sempre selezionate secondo le priorità definite dal Product Owner.
Lo Scrum Team identifica quindi le azioni o attività necessarie per l’implementazione dei deliverable richiesti per realizzare la User Story e soddisfare i criteri di accettazione, creando una Lista delle Attività, un elenco completo che comprende tutte le attività che lo Scrum Team si è impegnato a compiere nello Sprint corrente. La Lista delle Attività deve includere gli eventuali impegni necessari per il testing e l‘integrazione, in modo che l‘Incremento di Prodotto frutto dello Sprint possa essere integrato con successo nei deliverable prodotti dagli Sprint precedenti.
I membri dello Scrum Team usano la Lista delle Attività per stimare la durata e l‘impegno necessario per completare le User Story nello Sprint. I Criteri di Stima possono essere espressi in molti modi, fra questi un esempio tipico sono gli story point. I valori degli story point sono utilizzati per rappresentare lo sforzo relativo o comparato occorrente per completare un’attività.
L‘elenco delle attività che devono essere eseguite dallo Scrum Team nello Sprint è chiamato Sprint Backlog. Ogni Sprint ha il suo specifico Sprint Backlog, che viene creato durante la pianificazione dello Sprint in corso. Lo Sprint Backlog è la componente stabile del framework Scrum, per sua natura adattivo e flessibile. Infatti, una volta che lo Sprint Backlog è ultimato e preso in carico dallo Scrum Team, la regola è che non debba essere più modificato. Se durante uno Sprint emergono nuovi requisiti, saranno aggiunti al Prioritized Product Backlog (che a contrario dello Sprint Backlog è dinamico e in costante cambiamento) e inclusi in uno Sprint futuro.
Questo modo di procedere sostanzia ulteriormente il concetto della customer value driven delivery.
Gli output del processo Illustrare e Convalidare lo Sprint (deliverable accettati, deliverable rifiutati, rischi aggiornati, risultati dell’Analisi dell’Earned Value) forniscono informazioni preziose durante l‘esecuzione del processo di Retrospettiva dello Sprint. Il Retrospect Sprint Meeting è un elemento importante del concetto di ispezione-adattamento del framework Scrum e costituisce il passo finale di uno Sprint. Tutti i membri dello Scrum Team partecipano alla riunione, che viene facilitata o moderata dallo Scrum Master. È consigliata, ma non obbligatoria, la partecipazione del Product Owner. Uno dei membri del team funge da segretario verbalizzante e documenta le discussioni e i punti delle azioni future. È fondamentale tenere questa riunione in un ambiente aperto e rilassato per incoraggiare la piena partecipazione di tutti i membri del team. L‘obiettivo primario della riunione è quello di identificare tre elementi specifici:
1) Cose che il team desidera continuare a fare: best practice
2) Cose che il team desidera iniziare a fare: miglioramenti dei processi
3) Cose che il team desidera non fare più: problemi e ‘colli di bottiglia’ dei processi.
Queste aree vengono discusse e viene creato un elenco di Miglioramenti Fattibili Concordati.
Ma come avviene la consegna al cliente dei deliverable accettati? Per la risposta continuate a seguirci …
Lo Staff di PME
(1)Per saperne di più su prioritizzazione e User Story si consiglia di leggere i precedenti post Scrum in pillole #6 e Scrum in pillole:le User Story.
Continua il nostro impegno a rendere fruibili in brevi pillole tutti i preziosi contenuti della Guida SBOK®, tradotta da PME in lingua Italiana per conto di SCRUMstudy, a vantaggio di tutti coloro che vogliono conoscere più a fondo Scrum, e magari anche capire se una certificazione Scrum potrebbe essere loro di aiuto nel percorso di crescita professionale.
L’argomento di oggi è come si passa dalla scrittura e prioritizzazione delle User Story che formano il Prioritized Product Backlog alla realizzazione di incrementi di prodotto o servizio, o più genericamente deliverable, funzionanti, e perciò accettati dal Product Owner e potenzialmente consegnabili al cliente(1).
Il primo passo è la pianificazione dello Sprint. Lo Scrum Team si riunisce negli Sprint Planning Meeting per pianificare il lavoro da portare a termine nello Sprint. Il team rivede le User Story Stimate che si trovano in cima al Prioritized Product Backlog. Il Product Owner partecipa a questa riunione, nel caso siano necessari chiarimenti sulle User Story o sulle priorità. Per aiutare a fare in modo che il gruppo rimanga focalizzato sull‘argomento, questa riunione dovrà avere una durata predeterminata, con la lunghezza standard fissata in due ore per ogni settimana di durata dello Sprint. Questo aiuta a prevenire la tendenza a divagare in discussioni che dovrebbero essere in realtà intavolate in altre riunioni.
Lo Scrum Team prende in carico un sottoinsieme di User Story Stimate del Prioritized Product Backlog che ritiene di poter completare nello Sprint attuale sulla base della propria velocità. Le User Story Prese in Carico verranno sempre selezionate secondo le priorità definite dal Product Owner.
Lo Scrum Team identifica quindi le azioni o attività necessarie per l’implementazione dei deliverable richiesti per realizzare la User Story e soddisfare i criteri di accettazione, creando una Lista delle Attività, un elenco completo che comprende tutte le attività che lo Scrum Team si è impegnato a compiere nello Sprint corrente. La Lista delle Attività deve includere gli eventuali impegni necessari per il testing e l‘integrazione, in modo che l‘Incremento di Prodotto frutto dello Sprint possa essere integrato con successo nei deliverable prodotti dagli Sprint precedenti.
I membri dello Scrum Team usano la Lista delle Attività per stimare la durata e l‘impegno necessario per completare le User Story nello Sprint. I Criteri di Stima possono essere espressi in molti modi, fra questi un esempio tipico sono gli story point. I valori degli story point sono utilizzati per rappresentare lo sforzo relativo o comparato occorrente per completare un’attività.
L‘elenco delle attività che devono essere eseguite dallo Scrum Team nello Sprint è chiamato Sprint Backlog. Ogni Sprint ha il suo specifico Sprint Backlog, che viene creato durante la pianificazione dello Sprint in corso. Lo Sprint Backlog è la componente stabile del framework Scrum, per sua natura adattivo e flessibile. Infatti, una volta che lo Sprint Backlog è ultimato e preso in carico dallo Scrum Team, la regola è che non debba essere più modificato. Se durante uno Sprint emergono nuovi requisiti, saranno aggiunti al Prioritized Product Backlog (che a contrario dello Sprint Backlog è dinamico e in costante cambiamento) e inclusi in uno Sprint futuro.
Questo modo di procedere sostanzia ulteriormente il concetto della customer value driven delivery.
Gli output del processo Illustrare e Convalidare lo Sprint (deliverable accettati, deliverable rifiutati, rischi aggiornati, risultati dell’Analisi dell’Earned Value) forniscono informazioni preziose durante l‘esecuzione del processo di Retrospettiva dello Sprint. Il Retrospect Sprint Meeting è un elemento importante del concetto di ispezione-adattamento del framework Scrum e costituisce il passo finale di uno Sprint. Tutti i membri dello Scrum Team partecipano alla riunione, che viene facilitata o moderata dallo Scrum Master. È consigliata, ma non obbligatoria, la partecipazione del Product Owner. Uno dei membri del team funge da segretario verbalizzante e documenta le discussioni e i punti delle azioni future. È fondamentale tenere questa riunione in un ambiente aperto e rilassato per incoraggiare la piena partecipazione di tutti i membri del team. L‘obiettivo primario della riunione è quello di identificare tre elementi specifici:
1) Cose che il team desidera continuare a fare: best practice
2) Cose che il team desidera iniziare a fare: miglioramenti dei processi
3) Cose che il team desidera non fare più: problemi e ‘colli di bottiglia’ dei processi.
Queste aree vengono discusse e viene creato un elenco di Miglioramenti Fattibili Concordati.
Ma come avviene la consegna al cliente dei deliverable accettati? Per la risposta continuate a seguirci …
Lo Staff di PME
(1)Per saperne di più su prioritizzazione e User Story si consiglia di leggere i precedenti post Scrum in pillole #6 e Scrum in pillole:le User Story.
