Nel nostro ultimo appuntamento con le pillole, ci chiedevamo in che modo avviene la raccolta e documentazione dei requisiti in Scrum. Ed ecco qui la risposta, direttamente dalla Guida SBOK®, da noi tradotta in italiano, insieme a tutto il materiale di studio e alle domande di esame delle varie certificazioni Scrum, per conto di VMEdu, proprietaria del marchio SCRUMstudy.
Le User Story: questa è dunque la risposta alla domanda rimasta in sospeso.
Le User Story hanno una specifica struttura predefinita e costituiscono un modo semplice di documentare i requisiti e le funzionalità desiderate dall’utente finale. Una User Story ci racconta tre cose riguardo ai requisiti: Chi, Cosa e Perché. I requisiti espressi nelle User Story sono dichiarazioni brevi, semplici e di facile comprensione. Il formato tipico della User Story è il seguente: “Nella mia qualità di <ruolo/persona>, dovrei essere in grado di in modo da ”. Il formato standard predefinito si traduce in un miglioramento della comunicazione fra i vari stakeholder e in stime più precise da parte del team. Alcune User Story possono essere troppo grandi da gestire all’interno di un solo Sprint. Queste User Story di grandi dimensioni sono spesso chiamate Epic. Quando un’Epic viene scelta dal Prioritized Product Backlog per essere completata in uno Sprint imminente, si procede a scomporla ulteriormente in User Story più ridotte in termini di dimensioni e contenuto.
Il Prioritized Product Backlog è un elenco dinamico di User Story che viene continuamente aggiornato a causa dell’attività di ripioritizzazione e dell’introduzione ex novo, dell’aggiornamento, della rifinitura e a volte della cancellazione delle User Story. Questi aggiornamenti del backlog sono di norma il risultato di cambiamenti dei requisiti di business.
Ciascuna User Story ha dei Criteri di Accettazione associati. Le User Story sono soggettive, per cui i Criteri di Accettazione forniscono l’obiettività necessaria per poter considerare la User Story come ‘Done’ (fatta) o ‘not Done’ (incompiuta) in sede di Revisione dello Sprint. I Criteri di Accettazione chiariscono al team cosa ci si aspetta da una User Story, eliminano eventuali ambiguità presenti nei requisiti e aiutano ad allinearsi alle aspettative. Il Product Owner stabilisce e comunica i Criteri di Accettazione allo Scrum Team. Durante gli Sprint Review Meeting, i Criteri di Accettazione forniscono al Product Owner il contesto per decidere se una User Story è stata completata in modo soddisfacente. È importante – ed è una responsabilità dello Scrum Master – fare in modo che il Product Owner non modifichi nel mezzo di un Sprint i Criteri di Accettazione di una User Story presa in carico.
Per una migliore comprensione dei requisiti, alla scrittura di Epic e User Story viene accompagnata la creazione delle c.d. Persona. Le Persona sono personaggi immaginari molto dettagliati, che rappresentano la maggioranza degli utenti e degli altri stakeholder che non necessariamente utilizzeranno direttamente il prodotto finale. Le Persona sono create per identificare i bisogni della base di utenti target, aiutare il team a comprendere meglio gli utenti e i loro requisiti e obiettivi e supportare il Product Owner in una prioritizzazione più efficace delle funzionalità.
La Persona avrà un nome di fantasia, possibilmente un volto (preso da immagini di repertorio o liberamente utilizzabili), e attributi molto specifici come l’età, il genere, il livello di istruzione, l’ambiente in cui agisce, gli interessi e gli obiettivi. Si può inoltre aggiungere anche un motto che illustra e riassume i requisiti del gruppo tipo di utenti/Stakeholder incarnati dal personaggio fittizio.
Come vengono utilizzate le User Story per l’implementazione di un progetto gestito con Scrum? Lo vedremo nel nostro prossimo appuntamento con le pillole di Scrum. Continuate a seguirci!
Lo Staff di PME
Nel nostro ultimo appuntamento con le pillole, ci chiedevamo in che modo avviene la raccolta e documentazione dei requisiti in Scrum. Ed ecco qui la risposta, direttamente dalla Guida SBOK®, da noi tradotta in italiano, insieme a tutto il materiale di studio e alle domande di esame delle varie certificazioni Scrum, per conto di VMEdu, proprietaria del marchio SCRUMstudy.
Le User Story: questa è dunque la risposta alla domanda rimasta in sospeso.
Le User Story hanno una specifica struttura predefinita e costituiscono un modo semplice di documentare i requisiti e le funzionalità desiderate dall’utente finale. Una User Story ci racconta tre cose riguardo ai requisiti: Chi, Cosa e Perché. I requisiti espressi nelle User Story sono dichiarazioni brevi, semplici e di facile comprensione. Il formato tipico della User Story è il seguente: “Nella mia qualità di <ruolo/persona>, dovrei essere in grado di in modo da ”. Il formato standard predefinito si traduce in un miglioramento della comunicazione fra i vari stakeholder e in stime più precise da parte del team. Alcune User Story possono essere troppo grandi da gestire all’interno di un solo Sprint. Queste User Story di grandi dimensioni sono spesso chiamate Epic. Quando un’Epic viene scelta dal Prioritized Product Backlog per essere completata in uno Sprint imminente, si procede a scomporla ulteriormente in User Story più ridotte in termini di dimensioni e contenuto.
Il Prioritized Product Backlog è un elenco dinamico di User Story che viene continuamente aggiornato a causa dell’attività di ripioritizzazione e dell’introduzione ex novo, dell’aggiornamento, della rifinitura e a volte della cancellazione delle User Story. Questi aggiornamenti del backlog sono di norma il risultato di cambiamenti dei requisiti di business.
Ciascuna User Story ha dei Criteri di Accettazione associati. Le User Story sono soggettive, per cui i Criteri di Accettazione forniscono l’obiettività necessaria per poter considerare la User Story come ‘Done’ (fatta) o ‘not Done’ (incompiuta) in sede di Revisione dello Sprint. I Criteri di Accettazione chiariscono al team cosa ci si aspetta da una User Story, eliminano eventuali ambiguità presenti nei requisiti e aiutano ad allinearsi alle aspettative. Il Product Owner stabilisce e comunica i Criteri di Accettazione allo Scrum Team. Durante gli Sprint Review Meeting, i Criteri di Accettazione forniscono al Product Owner il contesto per decidere se una User Story è stata completata in modo soddisfacente. È importante – ed è una responsabilità dello Scrum Master – fare in modo che il Product Owner non modifichi nel mezzo di un Sprint i Criteri di Accettazione di una User Story presa in carico.
Per una migliore comprensione dei requisiti, alla scrittura di Epic e User Story viene accompagnata la creazione delle c.d. Persona. Le Persona sono personaggi immaginari molto dettagliati, che rappresentano la maggioranza degli utenti e degli altri stakeholder che non necessariamente utilizzeranno direttamente il prodotto finale. Le Persona sono create per identificare i bisogni della base di utenti target, aiutare il team a comprendere meglio gli utenti e i loro requisiti e obiettivi e supportare il Product Owner in una prioritizzazione più efficace delle funzionalità.
La Persona avrà un nome di fantasia, possibilmente un volto (preso da immagini di repertorio o liberamente utilizzabili), e attributi molto specifici come l’età, il genere, il livello di istruzione, l’ambiente in cui agisce, gli interessi e gli obiettivi. Si può inoltre aggiungere anche un motto che illustra e riassume i requisiti del gruppo tipo di utenti/Stakeholder incarnati dal personaggio fittizio.
Come vengono utilizzate le User Story per l’implementazione di un progetto gestito con Scrum? Lo vedremo nel nostro prossimo appuntamento con le pillole di Scrum. Continuate a seguirci!
Lo Staff di PME
