Prioritizing User Stories

One of the most important survey results conducted by an important international organization, states that 64% of the functionalities included in software products are never or almost never used!
How come?!?
One way to avoid such a waste of resources, is to assign priorities to the user stories and to develop them starting from the highest.

---

 This post wants to address that 64% of features to be developed, which are never used by the final users once the product is deployed on production. After all, avoiding those features isn’t a way to reduce costs and time necessary to go live?

Let’s see how SCRUM faces to this issue.
As you probably know, the SCRUM framework provides three different roles: the team, the scrum master (SM) and the product owner (PO) (see URL). All of them are important. Maybe the team can be considered the most important, but for sure, SCRUM cannot work if any of those is missing.

This post is dedicated to the important role of the Product Owner and to one of its duties: prioritizing the features!

Once the gathering requirements phase is finished, the product owner should have in her hands a list of index/note cards in which are written the user stories.

The process of prioritization, must be conducted in order to:

1. Maximize and accelerate the ROI
2. Reduce risks

In order to maximize te ROI, the PO must have a clear understanding of what the customer wants in terms of: objectives, necessities, opportunities to reach, in one word, she must understand what is the actual Customer Business Value to gather.

Reducing risks, on the other hand, is primarily a matter of:

• Remove any impediments
• Give answers and explanations to any doubts or open points
• Deepen, if necessary, user stories that are not clear
• Execute as soon as possible any critical project activities

We can consider critical, an activity that will use a new technology not yet known to the team.
Or, furthermore, an activity that is one of the most important of the entire product, over which there are lot of expectations from the project stakeholders.

For the first case mentioned (new technology) is important to work on that feature as soon as possibile in order to “understand” the new technology and how to work with it. This will allow the team to capitalize the knowledge just acquired and will lower the risks.

Facing the second case (hot feature), it is again a matter of work quickly on it and to fast deliver it in order to receive, even here as soon as possible, feedback from the stakeholders.

Thus, it’s only a matter of assigning the right priorities, isnt’ it?! Yes but, how?

Actually, there are many methods available to achieve that goal, but the one I want to explore today, is the one that takes care of the customer business value and the risks associated to each feature, assigning to them an index (from 1 to 10 for example) in order to draw a point in a x/y graph.

This method is also mentioned in one of Mike Cohn’s books (Agile Estimating and Planning) that I strongly suggest to read.

So, let’s use Excel.

Create a new worksheet containing three columns: User story ID (or title), Business Value Index, Risk Index.

List all the user stories and for each one first assign a business value index: 1 for the lowest and 10 for the highest.
Higher values should be assigned to each activity that directly aims to one or more of the objectives to be achieved.
Lower values should be assigned to the activities not so important in achieving the goals like ancillary activites, maintenance or administrative activities, reports, etc.

Once a business value index is assigned for each feature, is time to provide risk indexes.
Higher values should be assigned to critical features like those that uses new technologies, those not well described or well understood, those that have  many interactions with external systems, those that will serve different typology of users and so on.
Lower values should be assigned to the remaining acitivities.

Now it’s time to create a graph, having excel plotting the points.

Now, compare the graph you obtained with the reference matrix above reported.

Well, it is time to start working and remember: the features never or almost never used, are the ones having a lower business value assigned; so, do them at the end and, furthermore, try to avoid those with an high risk associated!

SCRUM (1^ parte)

In un post precedente, raccontavo di come poter conciliare realtà aziendali lontane da un modello di business prevalentemente orientato ai progetti (matrice debole), con le tematiche agili, tanto in voga in questi periodi.
Questo è il primo post di una piccola serie, in cui fornisco indicazioni rispetto a SCRUM: uno dei più utilizzati framework agili.  

---

Vorrei cominciare enunciando i diversi “perché” potresti, o dovresti,  decidere di utilizzare SCRUM per gestire i progetti nella tua azienda.  

• Perché non esiste un’analisi dettagliata del lavoro da eseguire
• Perché è necessario fornire al più presto al committente, valore di business, anche parziale, attraverso il prodotto rilasciato
• Perché i change di progetto potrebbero essere frequenti in rapporto alla volatilità del mercato di riferimento in cui si opera
• Perché la tecnologia utilizzata è innovativa o poco sperimentata
• Perché i rischi sono molto alti
• Perché è necessario ricevere feedback dagli utenti con buona frequenza

Ti ritrovi in qulcuno dei punti sopraccitati?  

Bene!  SCRUM potrebbe aiutarti a trovare le risposte giuste…SEGUIMIIIIIII!!  

 

Come funziona?

SCRUM suddivide il lavoro in tempi precisi, dà loro il nome di sprint e identifica una durata media di 2/4 settimane ognuno.  

Quando terminato, lo sprint permette di rilasciare in produzione un “pezzo di prodotto” funzionante, sin da subito utilizzabile dal committente.  Identifica ruoli che hanno perimetri di responsabilità ben definiti, chiari a tutti e regolamentati.

 Non necessita di analisi e piani di progetto “ultra-dettagliatissimi“. Solitamente SCRUM dedica a tali attività solo il 20% del tempo impiegato dalla normale attività di project management. 

Solo lo sprint corrente si giova di analisi sufficientemente approfondite, cosa non obbligatoria per i successivi sprint.
Questi ultimi, infatti, verranno particolareggiati quando arriverà il loro turno.  

Prevede infine, regole ben definite che scandiscono rapporti, tempistiche, modalità e strumenti, permettendo agli appartenenti al team, di essere efficienti, efficaci, focalizzati.  

Quali i principi ispiratori?

I principi ispiratori sono ovviamente mutuati dal manifesto agile. 

1. Soddisfare le esigenze del cliente
2. Accettazione dei change di progetto come normali accadimenti
3. Rilasciare prodotti funzionanti, anche parziali, frequentemente
4. Far lavorare a strettissimo contatto i tecnici, gli ingegneri e le persone più vicine al business
5. Puntare all’eccellenza tecnica, di design e di qualità
6. Essere motivati e motivare il team
7. Preferire comunicazioni dirette (face-to-face)
8. Ritmi lavorativi sostenibili
9. Semplicità a 360°
10. Retrospezione dell’operato

Cos’è esattamente SCRUM

SCRUM è un framework che permette il governo agile dei progetti. Riguarda essenzialmente il processo, gli strumenti, le persone, le modalità; non detta leggi inerenti le tecnicalità o le modalità in cui svolgere il lavoro che produce il prodotto, bensì ne governa l’avanzamento.  

E’ un approccio facilmente adattabile a progetti software, ma portabile anche a progetti di tipo hardware, marketing, operation (solo per citare alcuni esempi).  

Sono diverse le dimensioni dello SCRUM:  

• Strumenti e artefatti (Artifacts)
• Tempistiche precise (Time boxes)
• Ruoli (Roles)
• Regole (Rules)

Artifacts

   

Product Backlog

E’ il registro delle funzionalità necessarie, ordinate per importanza.  

Il Product Owner è il responsabile unico di tale registro.  

Egli, con l’aiuto degli altri stakeholder, comincia con la compilazione delle user stories: casi d’uso dell’applicazione descritte per singola tipologia d’utente.  

Dalle user stories vengono derivate le diverse funzionalità che le compongono e queste vengono elencate.  

In base alle priorità dello sponsor/committente, ai rischi identificati, al grado di dettaglio disponibile, alle funzionalità vengono assegnate priorità.  

E’ proprio da quelle in cima a quella lista che si comincerà a lavorare.  

Release Backlog

E’ un sottoinsieme del product backlog: identifica le funzionalità da implementare, raggruppate per versioni di prodotto che verranno rilasciate in produzione.  

Sprint Backlog

Rappresenta l’insieme delle funzionalità in ordine di priorità, che dovranno essere implementate nello sprint corrente.  

Queste vengono analizzate, scomposte in task, stimate dal team e prese in carico dai singoli componenti.  

Burndown chart

   

E’ un grafico che rappresenta il totale del lavoro mancante (ore o punti) suddiviso per giorno.  

Via via che il team evaderà lavoro, il trend della linea sarà discendente. E’ una rappresentazione che restituisce immediatezza rispetto alla resa e alle performance del team.  

Impediments Backlog

Lista degli impedimenti o dei problemi identificati, che risultano essere ostacoli al libero svolgimento del lavoro.  

Tale registro è gestito dallo Scrum Master, il quale dovrebbe affrontare e risolvere, nella teoria, i problemi emersi entro 24h dalla loro nascita.  

Bene per questa sera può bastare….nel prossimo post ripartiamo da qui: time boxes, ruoli e regole. 

Have a nice evening

L’importanza del team

Se vuoi arrivare primo, corri da solo.
Se vuoi andare lontano, cammina insieme agli altri.
(proverbio del Kenya)

 

L’importanza del gruppo è risaputa e assodata.
E’ vero, il singolo è agile e risponde velocemente ai cambi di scenario, ma la fragilità dovuta a risorse limitate gli precludono molte delle strade percorribili.

La forza del gruppo deriva dal fatto che questo, nel suo complesso, ha risorse e conoscenze maggiori e, in teoria, nessun obiettivo gli è precluso.

 

La minore agilità potrebbe però pesare in situazioni che richiedono forte dinamicità.

Il team agile

La teoria agile ci insegna che se un team, comunque contenuto nei numeri, ha le caratteristiche che seguono, riesce ugualmente a fare fronte a situazioni di forti cambiamenti e flessibilità.

Caratteristiche principali di un team agile:

• Orientamento verso l’effettivo valore di business del cliente
• Competenze tecniche professionali elevate dei singoli
• Dimensione ridotta del team
• Auto-disciplina nella risoluzioni di conflitti
• Personalità dei membri orientata alla collaborazione
• Buone capacità di adattamento
• Disponibilità e apertura dei singoli, all’apprendimento

Un buon leader, quindi, deve essere in grado di scegliere le persone giuste e, dal mio punto di vista,  iniziarle alla disciplina agile, creando continui stimoli volti alla comunicazione e condivisione degli obiettivi.

In questo modo sarà per lui possibile puntare a mete difficilmente raggiungibili come singolo, ma più facilmente avvicinabili come gruppo.

Comunicare le responsabilità dei singoli

Altro fattore fondamentale nella gestione del team è la comunicazione.

Questa deve essere immediata, diretta (face-to-face), chiara, semplice (vedi post precedente ‘Comunicazione Agile’).

E’ necessario che ogni membro del team conosca in ogni istante le attività a lui assegnate e le relative responsabilità.

Per ottenere risultati certi è bene fare uso di strumenti di assegnazione delle responsabilità come i seguenti.

Diagrammi gerarchici:

• WBS: identificando il responsabile di ogni WorkPackage della WBS
• OBS: struttura gerarchica organizzata per funzioni, dipartimenti e persone che saranno coinvolte nel progetto
• RBS: struttura gerarchica organizzata per tipologia di risorsa, utile anche per tracciare i costi.

Diagrammi a matrice:

• RAM : usata per illustrare le connessioni tra il lavoro necessario e i membri del Team. Può essere vista come incrocio della WBS e della OBS.
• RACI (vedi post ‘Commitment e responsabilità’): particolare formato di RAM (Responsible, Accountable, Consult and Inform) che mostra anche il grado di  coinvolgimento ai vari livelli.

La delega

Il project manager ha un importante altro strumento per ottenere responsabilità e commitment dai membri del team e che, contemporaneamente, gli permette di “guadagnare” tempo sul progetto: la delega.

La delega è definita come il decentramento temporale di responsabilità senza modificare il ruolo del collaboratore perché è limitata nei contenuti e nel tempo.

Delegare significa quindi assegnare compiti e relative responsabilità ad altre persone, attribuendo loro gli strumenti di cui hanno bisogno per eseguirli, esigendo che rispondano dei risultati conseguiti.

Il processo di delega dovrebbe quindi tenere conto di:

• chi assegna la delega e chi la riceve
• a cosa è circoscritta la delega (contesto)
• quale responsabilità comprende la delega (raggiungimento obiettivi)
• quali gli strumenti forniti al delegato
• come misurare il risultato della delega

Crescita del team

Una volta responsabilizzato e allineato il team, è necessario poi procedere a svilupparne le competenze, sia in termini di technicalities sia di soft skills.

Questo è possibile dedicando l’opportuna attenzione alle seguenti tematiche:

• Fomazione: tutte le attività volte a migliorare le competenze del team.
• Team building: attività volte a migliorare la coesione tra i membri del team.
• Ground rules: stabiliscono regole chiare (ricordate la KISS rule?) per quanto riguarda l’approccio lavorativo dei  membri. Riducono conflitti e incomprensioni.
• Co-location: collocazione fisica dei membri del team nello stesso luogo per migliorare il lavoro di gruppo e favorire la comunicazione e la libera circolazione dell’informazione.
• Riconoscimenti: favorire i premi di tipo win-win (vince il gruppo) rispetto ai win-lose (vince uno e perdono gli altri). Devono essere chiari, espliciti e raggiungibili.

Mettendo in atto quanto sopra, si otterranno principalmente tre grossi vantaggi: miglioramento delle competenze dei singoli, aumento dell’efficacia complessiva del gruppo e sensibile diminuzione del turn-around tra i membri.

E secondo voi? Quanto è importante un team in un progetto?

Puntiamo al sodo

Per natura ho una certa predisposizione alla pragmaticità.
Nel lavoro raramente pratico il gold-plating e cattedrali nel deserto ne ho costruite ben poche.
Questo approccio prevede una contropartita da regolare: posso perdere alcuni dettagli o sfumature o a volte il mio interlocutore può percepirmi come poco sensibile alle sue istanze più particolari.
Accetto il rischio. Cerco comunque di mantenermi vigile per evitare di commettere tali errori.

Citano alcuni testi di project management: un progetto si può ritenere concluso con successo, quando termina nei tempi e nei costi prestabiliti e quando sono state realizzate tutte le funzionaltà previste e solo quelle previste.

Questa citazione spalanca la porta alle tematiche agili.

Partiamo dal documento costituitente della disciplina agile (manifesto per lo sviluppo agile di software).
In quel documento sono esplicitamente evidenziati i quattro pilastri su cui si sviluppa l’intera disciplina e soprattuto su quali questioni deve essere posto il maggiore accento:

• Gli individui e le interazioni più dei processi e degli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione del contratto
• Rispondere al cambiamento più che seguire i piani

Nascosta tra le righe io ci leggo una sola parola: concretezza.

Customer Value

La teoria agile mette al centro della sua esistenza il concetto di customer value, che potremmo così sintetizzare:

il giusto prodotto, al giusto prezzo, nei giusti tempi.

Ma come possiamo definire “giusto” un prodotto, il suo prezzo e i relativi tempi di realizzo?

• Il giusto prodotto, è quel prodotto che implementa tutte le funzionalità richieste dal cliente, solo quelle, e che abbiano le caratteristiche e qualità necessarie.
• Il giusto prezzo è quel prezzo, equo e correttamente comparato alle funzionalità, aspettative e al mercato.
• I tempi giusti sono i tempi minimi di realizzo del prodotto, che vadano più possibile incontro alle aspettative del cliente.

Quando lessi la prima volta la definizione sopra, sorrisi: alcune le consideravo definizioni ovvie, altre semplicemente utopiche.

Però mi fecero pensare.

Era in effetti capitato in alcune occasioni, che alla presentazione di un prodotto appena realizzato il cliente mi facesse notare come alcune funzionalità introdotte non le ritenesse importanti; anzi spesso mi chiedeva di disabilitarle per evitare incomprensioni da parte degli altri utenti.
Quanto tempo e soldi mi erano costate quelle inutili funzionalità?

Altro problema centrale rispetto alla soddisfazione del cliente, è il tempo di realizzo di un prodotto o servizio.
Prima però un’altra considerazione a riguardo: sappiamo riconoscere il vero valore di business del prodotto che il cliente ci ha commissionato? Sappiamo identificare le funzionalità centrali del prodotto stesso?
Certo, credo proprio di si; spesso però tali funzionalità sono le ultime, in ordine cronologico, che vengono sviluppate.

Le motivazioni sono valide: è necessario oraganizzare prima il progetto, le risorse, l’architettura e, se si tratta di uno sviluppo software, il database e una buona parte dell’interfaccia utente.
Il cliente, di questo passo, vedrà le caratteristiche primarie del prodotto praticamente alla fine del progetto stesso.

Come fare quindi per conciliare tempi adeguati e soddisfazione del cliente?
La risposta è sicuramente procedere con rilasci progressivi.

Rilasci Progressivi

Il cliente ha appena firmato il contratto che gli abbiamo presentato per la realizzazione del prodotto richiesto.
Qual’è il più classico degli errori in cui ricadiamo?
Sparire per un tot di settimane, per poi ricomparire con il prodotto finito; chi di voi non ci è cascato almeno una volta? Personalmente, nonostante mille auto-raccomandazioni, mi capita tuttora.
Risultati:

• il tempo trascorso senza contatti ha “raffreddato” il cliente
• alcune, se non tutte, le funzionalità del prodotto, non sono come il cliente se le aspettava
• la finestra temporale in cui il prodotto avrebbe riscontrato maggiore successo è ormai passato
• il prodotto dovrà essere testato e sicuramente verranno richieste modifiche o aggiustamenti che avranno una ricaduta pesante considerando che siamo ormai alla fine della sua realizzazione

Ecco allora che lo sviluppo iterativo del prodotto/servizio e la predisposizione di rilasci progressivi di prototipi, perfettamente funzionanti nelle loro seppur parziali funzionalità, potrebbe essere la risposta opportuna.

Come fare?
Prima di tutto partiamo dalla WBS di prodotto: essa ci restituisce uno spaccato preciso e immediato di tutte le funzionalità del prodotto.
Insieme al cliente procediamo a prioritizzarne le funzionalità: partendo da quelle a più alto valore di business.
Queste dovranno essere quelle che andremo a rilasciare il prima possibile, abbattendo rischi di misunderstanding, cercando e ottenendo feedback immediati proprio perché caratteristiche più volute dal cliente, aumentando la soddisfazione del cliente perché indirettamente percepisce di avere il suo prodotto in tempi molto brevi.

In virtù di quanto detto sopra a proposito di architettura e organizzazione del progetto, non è però sempre facile rilasciare subito tali funzionalità al cliente; è per questo che è assolutamente necessario coinvolgere il team.

Solo il team è in grado di fornire indicazioni, suggerimenti, scorciatoie per arrivare a tale risultato.
Ovviamente tutti i mebri del team devono condividere pienamente le motivazioni che portano ad una scelta del genere, pena il fallimento dell’operazione.