Dopo aver dedicato un post alla priorizzazione delle User Story, facciamo un salto nel “Program Level” (cit. SAFe) e soffermiamoci sul Program Backlog e, in particolare, sulle feature.

E’ possibile pensare alle feature come un aggregato di User Story, ovvero una vista ad alto livello di un gruppo di funzionalità affini che vengono realizzate per assolvere uno specifico compito.

In realtà, inizialmente, nel contesto Agile, si è cercato di introdurre la gerarchia Temi->Epic->User Story, ma questa, per motivi storici di utilizzo di termini analoghi largamente diffusi, è spesso sostituita da Epic->Feature->Work Item. Lo stesso TFS contempla esplicitamente le “feature”.

Feature in TFS 2013

Le feature sono un elemento fondamentale del processo di relazione tra committente-produttore, trasformando la Vision del Prodotto nelle macro-funzionalità che il sistema andrà ad offrire. In tal modo, si dota il Product Manager di uno strumento che gli permette di “dialogare” agevolmente con i Key Stakeholder, mentre il Product Owner diventa responsabile di un set di funzionalità da affidare al proprio Team.

Tipicamente, le feature vengono formalizzate dagli attori coinvolti nella definizione degli obiettivi di business (cosa che in DAD avviene nella fase di Inception), espressi nella classica User Voice Form:

Essendo un Utente telefonico, voglio poter ricevere notifiche automatiche da parte del mio operatore, così da attivarmi in caso di promozioni o problemi

Ma le feature non condividono con le User Story solo la forma descrittiva, in quanto anche la stima dell’effort viene tipicamente effettuata (con la dovuta valutazione della maggiore incertezza e l’occhio rivolto principalmente al business) in Story Point (Ideal Day). Il tutto è affidato al team di Product Management in congiunzione ai Product Owner.

Quello che invece si differenzia sensibilmente è l’attività di priorizzazione.

Di primo acchito si potrebbe ipotizzare di priorizzare la feature in base al ROI (Return of Investments), calcolato come il rapporto tra Valore (prezzo) e Costo di sviluppo. Il punto è che tale stima non tiene conto di un fattore che D. Reinertsen ha dimostrato essere fondamentale: il Cost of Dealy (CoD), ovvero il costo associato al ritardo dello sviluppo di una specifica funzionalità, calcolabile come aggregato di tre valori fondamentali: User value, Time value e Risk Reduction value.

Senza voler entrare troppo nella descrizione di dettaglio (per approfondimenti: The Principles of Product Development Flow: Second Generation Lean Product Development), Reinertsen propone alcune regole pratiche di priorizzazione:

• Se due feature hanno lo stesso CoD, è opportuno sviluppare prima quella che richiede meno effort;
• Se due feature richiedono lo stesso effort di sviluppo, è opportuno realizzare prima quella con il maggior CoD.

Il problema è che, nella maggior parte dei casi, è difficile effettuare una comparazione diretta tra l’effort e il CoD di due feature (ciò è vero soprattutto nell’ambito del software). Per questo è opportuno ricorrere ad una terza tattica:

• Se due feature hanno effort realizzativo e CoD differenti, è opportuno realizzare quella che minimizza il rapporto tra i due valori CoD/Effort. Tale tattica è definita come Weighted Shorted Job First (WSJF).

Facciamo un esempio pratico (scala dei valori da 1:10, con 10 valore massimo):

Dalla tabella si evince che la feature con maggiore priorità è la “A”, anche non avendo il maggior Valore per l’utente. Questo è assolutamente in linea con un approccio che non tiene solo conto del Valore, ma che armonizza vari aspetti (Valore, Tempo e Rischio), al fine di produrre il maggior Valore complessivo.

L’approccio appena presentato, seppur considerando fattori diversi orientati al business, è in linea con quello già proposto per il calcolo della priorità delle User Story, ottenendo, così, una soluzione più analitica e rigorosa rispetto alla semplice assegnazione di un valore basato esclusivamente sull’esperienza di chi effettua la stima stessa.