Come avviene la prioritizzazione dei requisiti in Scrum? Questo l’oggetto dell’ultimo interrogativo che avevamo lasciato in sospeso(1).
La risposta, sintetica ma al tempo stesso esaustiva, è che tutto passa dal concetto di Consegna Basata sul Valore per il Cliente. Avendo presente che una delle caratteristiche chiave di qualsiasi progetto è l’incertezza degli esiti e dei risultati, e che è impossibile garantire il successo del progetto, a prescindere dalla sua dimensione o complessità, Scrum ritiene fondamentale iniziare a consegnare risultati concreti quanto prima possibile nel corso del progetto. Poiché il valore rappresenta la ragioni principale per la quale qualsiasi organizzazione va avanti con un progetto, la Consegna basata sul Valore deve essere quindi l’obiettivo primario. La consegna anticipata di risultati, e perciò di valore, offre l’opportunità di reinvestire e dimostra la validità del progetto agli stakeholder interessati. Scrum facilita la consegna di valore fin dalle primissime fasi del progetto e continua a farlo per tutto il ciclo di vita del progetto.
Per poter realizzare una Consegna basata sul Valore, è importante:
1. Capire cosa aggiunge valore per i clienti e gli utenti e mettere i requisiti di alto valore in cima alla lista delle priorità del Prioritized Product Backlog.
2. Diminuire l’incertezza e far fronte costantemente ai rischi che potrebbero diminuire il valore qualora si materializzassero. È inoltre importante lavorare a stretto contatto con gli stakeholder del progetto mostrando loro gli incrementi di prodotto alla fine di ogni Sprint, rendendo così possibile un’efficace gestione del cambiamento.
3. Creare i Deliverable sulla base delle priorità stabilite, producendo incrementi di prodotto potenzialmente consegnabili durante ogni Sprint, in modo tale che i clienti inizino a realizzare valore fin dalle prime battute del progetto.
Il concetto di Consegna basata sul Valore proprio di Scrum rende questo framework molto allettante per gli stakeholder e il business senior management. Questo concetto è molto diverso rispetto ai modelli predittivi di project management.
Pianificare il progetto basandosi sul valore significa da un lato individuare tutti gli elementi che non aggiungono valore ad un processo (Value Stream Mapping) e dall’altro implementare per prime le funzionalità/requisiti (che in Scrum si traducono in User Story) che hanno il valore più elevato per il Cliente. Queste User Story ad alto valore vengono collocate in cima al Prioritized Product Backlog.
Un team può utilizzare una molteplicità di schemi di prioritizzazione per determinare le funzionalità ad alto valore.
a. Schemi Semplici: Gli schemi semplici consistono nel classificare gli elementi come Priorità “1”, “2”, “3” o “Alta”, “Media” e “Bassa” e così via. Anche se si tratta di un approccio semplice e trasparente, può causare dei problemi perché spesso c’è la tendenza a classificare tutto come Priorità “1” o “Alta”.
b. Prioritizzazione MoSCoW : Lo schema di prioritizzazione MoSCoW prende il nome dalle prime lettere delle frasi ‘Must have’ (cioè ‘Deve avere’), ‘Should have’ (cioè ‘Dovrebbe avere’), ‘Could have’ (cioè ‘Potrebbe avere’), e ‘Won’t have’ (cioè ‘Non avrà’). Questo metodo di prioritizzazione è generalmente più efficace degli schemi semplici. Le categorie sono in ordine decrescente di priorità, dove le funzionalità del tipo ‘Must have’ sono quelle senza le quali il prodotto non avrà valore e quelle del tipo ‘Won’t have’ sono quelle che, anche se sarebbe bello avere, non è necessario includere.
c. Monopoly Money : Questa tecnica consiste nel consegnare ai clienti una quantità di “soldi del Monopoli” o “soldi falsi” pari al budget del progetto, chiedendo loro di distribuirli fra le User Story prese in esame. In questo modo, il cliente fa una scala di priorità in base a ciò che è disposto a pagare per ciascuna User Story.
d. Metodo dei 100 Punti: Consiste nel mettere a disposizione del cliente 100 punti, che lo stesso può utilizzare per votare per le funzionalità che ritiene più importanti.
e. Analisi di Kano: L’Analisi di Kano è stata sviluppata da Noriaki Kano nel 1984 e consiste nel classificare le funzionalità o i requisiti in quattro categorie basate sulle preferenze del cliente: 1. Exciters/Delighters (cioè che provocano eccitazione e meraviglia): Funzionalità che sono nuove o hanno un valore elevato per il cliente; 2. Satisfiers (cioè che soddisfano): Funzionalità che offrono valore al cliente; 3. Dissatisfiers (cioè che non soddisfano): Funzionalità che, se non presenti, determinano con ogni probabilità il non gradimento del prodotto da parte del cliente, ma che, se presenti, non incidono sul suo livello di soddisfazione. 4. Indifferent (cioè che sono indifferenti): Funzionalità che non influenzeranno in alcun modo il cliente e che dovrebbero essere eliminate.
Quando e come avviene la identificazione e scrittura dei requisiti? Continuate a seguire le nostre pillole e lo scoprirete …
Lo Staff di PME
Come avviene la prioritizzazione dei requisiti in Scrum? Questo l’oggetto dell’ultimo interrogativo che avevamo lasciato in sospeso(1).
La risposta, sintetica ma al tempo stesso esaustiva, è che tutto passa dal concetto di Consegna Basata sul Valore per il Cliente. Avendo presente che una delle caratteristiche chiave di qualsiasi progetto è l’incertezza degli esiti e dei risultati, e che è impossibile garantire il successo del progetto, a prescindere dalla sua dimensione o complessità, Scrum ritiene fondamentale iniziare a consegnare risultati concreti quanto prima possibile nel corso del progetto. Poiché il valore rappresenta la ragioni principale per la quale qualsiasi organizzazione va avanti con un progetto, la Consegna basata sul Valore deve essere quindi l’obiettivo primario. La consegna anticipata di risultati, e perciò di valore, offre l’opportunità di reinvestire e dimostra la validità del progetto agli stakeholder interessati. Scrum facilita la consegna di valore fin dalle primissime fasi del progetto e continua a farlo per tutto il ciclo di vita del progetto.
Per poter realizzare una Consegna basata sul Valore, è importante:
1. Capire cosa aggiunge valore per i clienti e gli utenti e mettere i requisiti di alto valore in cima alla lista delle priorità del Prioritized Product Backlog.
2. Diminuire l’incertezza e far fronte costantemente ai rischi che potrebbero diminuire il valore qualora si materializzassero. È inoltre importante lavorare a stretto contatto con gli stakeholder del progetto mostrando loro gli incrementi di prodotto alla fine di ogni Sprint, rendendo così possibile un’efficace gestione del cambiamento.
3. Creare i Deliverable sulla base delle priorità stabilite, producendo incrementi di prodotto potenzialmente consegnabili durante ogni Sprint, in modo tale che i clienti inizino a realizzare valore fin dalle prime battute del progetto.
Il concetto di Consegna basata sul Valore proprio di Scrum rende questo framework molto allettante per gli stakeholder e il business senior management. Questo concetto è molto diverso rispetto ai modelli predittivi di project management.
Pianificare il progetto basandosi sul valore significa da un lato individuare tutti gli elementi che non aggiungono valore ad un processo (Value Stream Mapping) e dall’altro implementare per prime le funzionalità/requisiti (che in Scrum si traducono in User Story) che hanno il valore più elevato per il Cliente. Queste User Story ad alto valore vengono collocate in cima al Prioritized Product Backlog.
Un team può utilizzare una molteplicità di schemi di prioritizzazione per determinare le funzionalità ad alto valore.
a. Schemi Semplici: Gli schemi semplici consistono nel classificare gli elementi come Priorità “1”, “2”, “3” o “Alta”, “Media” e “Bassa” e così via. Anche se si tratta di un approccio semplice e trasparente, può causare dei problemi perché spesso c’è la tendenza a classificare tutto come Priorità “1” o “Alta”.
b. Prioritizzazione MoSCoW : Lo schema di prioritizzazione MoSCoW prende il nome dalle prime lettere delle frasi ‘Must have’ (cioè ‘Deve avere’), ‘Should have’ (cioè ‘Dovrebbe avere’), ‘Could have’ (cioè ‘Potrebbe avere’), e ‘Won’t have’ (cioè ‘Non avrà’). Questo metodo di prioritizzazione è generalmente più efficace degli schemi semplici. Le categorie sono in ordine decrescente di priorità, dove le funzionalità del tipo ‘Must have’ sono quelle senza le quali il prodotto non avrà valore e quelle del tipo ‘Won’t have’ sono quelle che, anche se sarebbe bello avere, non è necessario includere.
c. Monopoly Money : Questa tecnica consiste nel consegnare ai clienti una quantità di “soldi del Monopoli” o “soldi falsi” pari al budget del progetto, chiedendo loro di distribuirli fra le User Story prese in esame. In questo modo, il cliente fa una scala di priorità in base a ciò che è disposto a pagare per ciascuna User Story.
d. Metodo dei 100 Punti: Consiste nel mettere a disposizione del cliente 100 punti, che lo stesso può utilizzare per votare per le funzionalità che ritiene più importanti.
e. Analisi di Kano: L’Analisi di Kano è stata sviluppata da Noriaki Kano nel 1984 e consiste nel classificare le funzionalità o i requisiti in quattro categorie basate sulle preferenze del cliente: 1. Exciters/Delighters (cioè che provocano eccitazione e meraviglia): Funzionalità che sono nuove o hanno un valore elevato per il cliente; 2. Satisfiers (cioè che soddisfano): Funzionalità che offrono valore al cliente; 3. Dissatisfiers (cioè che non soddisfano): Funzionalità che, se non presenti, determinano con ogni probabilità il non gradimento del prodotto da parte del cliente, ma che, se presenti, non incidono sul suo livello di soddisfazione. 4. Indifferent (cioè che sono indifferenti): Funzionalità che non influenzeranno in alcun modo il cliente e che dovrebbero essere eliminate.
Quando e come avviene la identificazione e scrittura dei requisiti? Continuate a seguire le nostre pillole e lo scoprirete …
Lo Staff di PME
