I 3 ARTEFATTI SCRUM.
Buona lettura!
Gli Artefatti Scrum sono oggetti che Scrum crea, aggiorna e utilizza per il suo funzionamento.
Per fare un parallelismo, negli approcci tradizionali di Project Management, un Gantt, una WBS o un Project Charter possono essere considerati degli Artefatti.
Ognuno degli Artefatti Scrum:
- può far riferimento al valore da produrre o al lavoro da effettuare
- è specificatamente pensato per supportare l’approccio empirico caratteristico di Scrum, garantendo la trasparenza delle informazioni che contiene in modo che chiunque analizzi un Artefatto (Inspect) avrà sempre tutte le informazioni necessarie per pianificarne l’adattamento (Adapt)
- ha associato un suo Commitment (novità introdotta dall’ultima versione della Scrum Guide).
Il concetto di Commitment è cruciale in Scrum, non a caso Commitment è anche uno dei 5 Valori del framework, e, in riferimento agli Artefatti Scrum, rappresenta:
- un “impegno” che lo Scrum Team si assume rispetto ad ogni Artefatto, qualcosa che si impegna a raggiungere
- un elemento rispetto al quale è in grado di misurarsi (misurare quanto è vicino o lontano l’obiettivo da raggiungere)
- una guida, una bussola che indica sempre, per ogni Artefatto, la direzione da seguire, la meta ultima da raggiungere. E’, perdonami la metafora spericolata, “la luce in fondo al tunnel” che ci guida quando non sappiamo bene cosa fare, siamo confusi o le cose si fanno complicate.
In sintesi:
| ARTEFATTI SCRUM | RAPPRESENTA |
COMMITMENT ASSOCIATO |
|
Product Backlog |
Lavoro da effettuare (per creare il Prodotto) | Product Goal |
|
Sprint Backlog |
Lavoro da effettuare (per creare un Incremento) |
Sprint Goal |
| Increment | Valore da produrre entro la fine dello Sprint |
Definition Of Done |
Artefatti Scrum: il PRODUCT BACKLOG.
Analizziamo la frase punto per punto.
Il Product Backlog è la sola e unica fonte di tutto il lavoro da effettuare.
In Scrum tutto ciò che facciamo per creare, evolvere o mantenere un prodotto è gestito da un solo team di professionisti, lo Scrum Team che, come sappiamo, è cross-funzionale: è autonomo, basta a se stesso, ha tutte le competenze necessarie per completare il suo lavoro e quindi non dipende (o non dovrebbe dipendere) da nessun altro che sia esterno al team stesso.
Dal momento che tutto ciò che riguarda il prodotto viene gestito dallo Scrum Team, non avrebbe alcun senso avere repository diversi per gestire le varie tipologie di attività.
Requisiti funzionali, change, attività di improvement o di mitigazione dei rischi, sperimentazioni (Spike), bug fix, requisiti tecnici (prestazionali, relativi alla sicurezza, etc.) o di compliance: tutto ciò che dobbiamo fare è contenuto nel Product Backlog che è quindi la sola e unica fonte di tutto il lavoro (ancora) da effettuare (Work yet to be done).
Ogni item del Product Backlog (o PBI, Product Backlogi Item) rappresenta una attività da svolgere per creare, mantenere o evolvere il Prodotto.
Il Product Backlog è un elenco ordinato.
Tutti gli Eventi di Scrum sono timeboxed: hanno una durata massima superata la quale l’Evento termina, sempre e senza eccezioni, anche se ci cade un meteorite sul tetto di casa! 😊
Nel tempo limitato di un Sprint (massimo un mese) lo Scrum Team avrà una capacità produttiva limitata e dovrà decidere quali sono gli item da completare prima e quali invece dovranno necessariamente attendere gli Sprint successivi.
Mantenere ordinato il Product Backlog ci costringe a fare una scelta tra cosa è prioritario e va completato il prima possibile e cosa lo è meno e può essere rimandato ad un momento successivo.
L’ordinamento del Product Backlog è una questione che attiene al business e la responsabilità ricade quindi sul Product Owner: “massimizzare il valore realizzato attraverso il lavoro dello Scrum Team” significa ottimizzare il tempo che il team ha a disposizione per completare prima ciò che ha maggior valore.
Il Product Backlog è un elenco emergente
Il Product Backlog è un elenco emergente i cui i dettagli emergono a mano a mano che il lavoro procede, la conoscenza si fa più profonda, i dubbi trovano risposte, la soluzione viene raffinata, le stime o il sizing diventano via via più puntuali.
Un Product Backlog ben gestito è un oggetto dinamico, mai completo e sempre in divenire, una fotografia dello scope del prodotto in un dato momento, scope che viene dettagliato e approfondito per approssimazioni successive.
Le nuove esigenze espresse dagli stakeholders, i cambiamenti nel contesto organizzativo, di mercato o normativo (cambiano le priorità o la strategia della nostra organizzazione, dobbiamo gestire un nuovo competitor o soddisfare nuove normative o leggi, etc.) si traducono in un aggiornamento del Product Backlog.
Finché esiste il prodotto esiste anche il suo Product Backlog.Il Product Backlog è un artefatto di business e, come tale, ricade sotto la responsabilità del proprietario del prodotto: il Product Owner.
E’ compito del Product Owner:
- mantenerlo sempre aggiornato, ordinato, consistente e trasparente
- renderlo emergente attraverso una costante attività di Refinement (una volta si chiamava Grooming): l’atto di scomporre i PBIs in elementi più atomici e precisi, di definirli ulteriormente e di aggiungere dettagli via via che emergono (dettagli che possono variare in base al contesto specifico).
Il Refinement è l’attività che permette ai PBIs di raggiungere quel grado di chiarezza e trasparenza tale da renderli:
- selezionabili in un evento di Sprint Planning (“Ready”)
- completabili in uno Sprint (“Done“).
Product Backlog Refinement
Sebbene la responsabilità del Product Backlog (contenuto e ordinamento) competa al Product Owner, la stima dell’effort/sizing associata ad ogni item è una responsabilità inviolabile dei Developer e la regola non ammette eccezioni.
Urge a questo punto aprire una parentesi piccola ma necessaria.
Il fatto che il Product Owner abbia la responsabilità del Product Backlog e i Developer siano responsabili per le stime e le scelte tecniche, non significa affatto che entrambi svolgano il loro compito in assenza di dialogo. Al contrario il due ruoli collaborano costantemente, l’uno influenzando le scelte dell’altro e le decisioni prese sono, di solito, il frutto della loro negoziazione e del loro confronto.
D’altra parte, per interpretare correttamente il modello di gestione decentralizzato di Scrum, è necessario chiarire i perimetri di responsabilità dei diversi ruoli ma senza mai dimenticare che i concetti di ownership, collaborazione e trust si permeano a vicenda e costituiscono il substrato culturale fondante del framewok.
Roman Pichler ci suggerisce di rendere DEEP (giocando sul significato di “profondo” dell’acronimo D.E.E.P.) il nostro Product Backlog.
|
D |
E | E |
P |
|
Detailed Appropriately |
Estimated | Emergent |
Prioritized |
| Gli item del Product Backlog con una priorità più alta conterranno maggiori dettagli e un livello di contesto maggiore rispetto a quelli con priorità più bassa. | Tutti gli item del Product Backlog dovrebbero essere stimati (in termini di complessità/effort) almeno a livello approssimativo.
Più aumenta la priorità dell’item più puntuale diventerà la sua stima. Sebbene Scrum non prescriva alcuna tecnica o unità di misura specifica da utilizzare per la stima, di solito questa è espressa in Story Point o Ideal Days.
|
Il Product Backlog è un artefatto organico: si evolve e cambia nel tempo.
Nuovi item emergono in base ai feedback di clienti, utenti o del mercato e vengono quindi aggiunti al Product Backlog. Gli item già presenti vengono aggiornati, riprioritizzati, dettagliati o eliminati. |
I PBIs sono prioritizzati ed ordinati. Gli item più importanti avranno una priorità più alta, verranno implementati per primi e si troveranno nella parte superiore del Product Backlog. Una volta implementati saranno concettualmente rimossi dal Product Backlog che, come dicevamo, rappresenta il Work yet to be done.
Scrum non prescrive una tecnica di prioritizzazione specifica ma le variabili considerate sono solitamente il rischio associato (il rischio è un anti-valore) il rapporto costi-benefici e le eventuali dipendenze tra i PBIs, |
Product Backlog DEEP
Possiamo descrivere il Product Backlog anche con la metafora dell’Iceberg:
- durante lo Sprint Planning Meeting l’Iceberg perde la sua forma a punta perché gli item a più alta priorità vengono selezionati per lo Sprint e spostati nello Sprint Backlog
- in seguito, grazie all’attività di Refinement, nuovi item vengono aggiunti al Product Backlog mentre altri salgono nella parte superiore del Product Backlog perché aumenta la loro priorità restituendo al Product Backlog la sua forma originaria.
Product Backlog Iceberg Shape
Product Backlog Commitment: Product Goal.
Al Product Backlog è associato il suo Commitment, il Product Goal.
La Scrum Guide è “volutamente incompleta” e non ci suggerisce come deve essere descritto il Product Goal o cosa dovrebbe contenere ma si limita a indicarci che il Product Goal:
- è contenuto nel Product Backlog: gli item da realizzare per soddisfarlo emergeranno via via che il lavoro procede e la conoscenza si fa più profonda
- descrive uno stato futuro del prodotto
- per lo Scrum Team, rappresenta un faro guida, una bussola, un obiettivo a lungo termine per pianificare l’evoluzione del prodotto stesso: lo Scrum Team si impegna a raggiungere il Product Goal entro la fine del progetto.
Il Product Goal:
- descrive il beneficio o il risultato specifico e misurabile, collegato alla strategia aziendale, che il prodotto deve realizzare
- definisce il contesto, crea allineamento tra gli stakeholder ed i team di sviluppo e orienta i loro sforzi verso una meta chiara e condivisa
- rappresenta la base con cui definire l’obiettivo di ogni singolo Sprint: lo Sprint Goal. Possiamo pensare ai diversi Sprint Goal come degli step incrementali di avvicinamento al Product Goal finale.
Esempi di Product Goal potrebbero essere: acquisire un certo numero di nuovi clienti, aumentare il tasso di conversione di una certa percentuale, generare revenue per un dato importo o lanciare un nuovo prodotto/servizio.
Un obiettivo alla volta.
They [aka The Scrum Team] must fulfill (or abandon) one objective before taking on the next. – Scrum Guide, Nov 2020
Una delle regole auree di Scrum, ma anche una delle regole più disattese da aziende e professionisti che affermano di adottare Scrum, è che è necessario raggiungere (o abbandonare) un obiettivo prima di affrontarne un altro. In altri termini, in Scrum non si deve (o non si dovrebbe) lavorare contemporaneamente su più progetti/iniziative nell’illusione che ciò possa tradursi in un qualche effetto positivo sulla produttività.
Il context switching, la difficoltà nello stabilire le priorità su iniziative diverse, l’incapacità di raggiungere lo “stato di flusso” sono tutti fenomeni, ampiamente documentati dalle neuroscienze, di come il multi-tasking sortisca, quasi sempre, l’effetto di farci iniziare tante cose senza portarne a termine nemmeno una (o, nel migliore dei casi, di completarle sacrificando la loro qualità, il che, in Scrum, equivale a non averle completate).
L’”effetto struzzo” è evidentemente uno dei bias cognitivi più radicati se, nonostante le evidenze, le aziende si ostinano ancora a pensare al multi-tasking come a una soluzione! 😊
Artefatti Scrum: lo SPRINT BACKLOG
Il secondo degli Artefatti Scrum è lo Sprint Backlog: un piano tattico creato da e per i Developer, costituito da:
- lo Sprint Goal (che rappresenta il WHY, il motivo per cui l’incremento dovrebbe aggiungere valore al prodotto)
- Gli item del Product Backlog selezionati per lo Sprint (che costituiscono il WHAT, quali PBIs dovremo completare per poter soddisfare lo Sprint Goal)
- Il piano operativo per trasformare quegli item in un Increment di valore (è l’HOW, la modalità con cui realizzeremo quegli item.
Ecco un esempio di come potrebbe essere strutturato il nostro Sprint Backlog:
| Sprint Goal Sprint 1 | |||||||||||
|
PBI/User Story |
Sizing/Estimate | Acceptance Criteria | Task Tecnici | Member Name | Planned Hours | Remaining hours | Monday | Tuesday | Wednesday | Thursday |
Friday |
| As a [role] I want to [do something) so that [banefit] | 8 Story Points | Acceptance Criteria 1 | Task 1 | Valentina | 5 | 2 | 1 | 2 | |||
| Acceptance Criteria 2 | Task 2 | Leonardo | 4 | 0 | 1 | 3 | |||||
| Acceptance Criteria 3 | Task 3 | Gabriele | 7 | 0 | 2 | 3 | 2 | ||||
| Task 4 | Matteo | 6 | 1 | 1 | 4 | ||||||
| Task 5 | Leonardo | 5 | 1 | 0 | 1 | 3 | |||||
| Task 6 | Gabriele | 8 | 1 | 3 | 2 | 1 | 1 | ||||
| As a [role] I want to [do something) so that [banefit] | 5 Story Points | Acceptance Criteria 1 | Task 1 | Leonardo | 8 | 3 | 2 | 3 | |||
| Acceptance Criteria 2 | Task 2 | Valentina | 4 | 2 | 1 | 0 | 1 | ||||
| Task 3 | Lorenzo | 5 | 0 | 0 | 1 | 3 | 1 | ||||
- Lo Sprint Goal sintetizza il WHY: QUALE È IL MOTIVO PER CUI LAVORIAMO IN QUESTO SPRINT? QUALE OBIETTIVO VOGLIAMO RAGGIUNGERE ENTRO LA FINE DELLO SPRINT? L’insieme degli Sprint Goal di tutti gli Sprint dovrebbero condurci alla fine a soddisfare il Product Goal
- I PBIs/User Story selezionate per lo Sprint rappresentano il WHAT: COSA DOBBIAMO FARE PER RAGGIUNGERE LO SPRINT GOAL?
- I diversi Task tecnici ed il piano con cui i Developer prevedono di completarli (chi ci lavorerà, per quante ore, etc.) costituisce l’HOW: COME REALIZZEREMO L’INCREMENTO PER RAGGIUNGERE LO SPRINT GOAL?
Lo Sprint Backlog è una fotografia trasparente e sempre aggiornata del lavoro che i Developer intendono svolgere durante lo Sprint per raggiungere lo Sprint Goal. Di conseguenza, viene continuamente verificato (Inspect) ed aggiornato (Adapt), durante lo Sprint, man mano che la conoscenza diventa più profonda.
L’evento formale in cui il piano viene verificato ed adattato è il Daily Scrum: questo vuol dire che i Developer misurano il loro avanzamento durante lo Sprint ed eventualmente ripianificano le loro attività almeno una volta al giorno.
Sprint Backlog Commitment: Sprint Goal.
Detto in altri termini, l’impegno dei Developer è verso il raggiungimento di un outcome (l’obiettivo rappresentato dallo Sprint Goal) e non verso l’output (l’insieme delle funzionalità da realizzare e la modalità con cui le realizzeremo). Il primo non è negoziabile e non può essere compromesso, il secondo è negoziabile e si raffina in modo emergente a mano a mano che, durante lo Sprint, la comprensione aumenta.
Lo Sprint Goal aiuta lo Scrum Team a mantenere coerenza e focus e fornisce quella prospettiva olistica che lo incoraggia a lavorare con un unico obiettivo condiviso piuttosto che su obiettivi verticali limitati al contributo tecnico di ogni membro del team. I Developer lavorano, durante lo Sprint, con lo Sprint Goal in mente a guidarne gli sforzi.
Se, durante lo Sprint, i Developer realizzano che il lavoro non sta avanzando in linea con quanto pianificato, collaborano con il Product Owner per rinegoziare/riadattare lo scope dello Sprint Backlog ma senza mai comprometterne l’obiettivo (rappresentato dallo Sprint Goal).
Un esempio di Product e Sprint Goal.
Proviamo a fare un esempio di come potrebbe presentarsi il nostro Product Goal e quale legame potrebbe avere con i diversi Sprint Goal.
- PRODUCT GOAL: Lanciare un nuovo sito web che ci permetta di vendere i nostri prodotti sul territorio italiano.
- SPRINT 1, SPRINT GOAL: Creare una landing page per pubblicare l’elenco dei nostri prodotti e le relative informazioni (Descrizione, Prezzo, Caratteristiche, etc.)
- SPRINT 2, SPRINT GOAL: Fornire all’Utente i meccanismi per chiedere informazioni sui nostri prodotti attraverso un modulo di contatto
- SPRINT 3, SPRINT GOAL: Fornire all’Utente i meccanismi per effettuare l’acquisto online di un prodotto attraverso Paypal
- SPRINT 3, SPRINT GOAL: Fornire all’Utente i meccanismi per effettuare l’acquisto online di un prodotto attraverso il circuito Mastercard
Artefatti Scrum: l’INCREMENT.
Il terzo degli Artefatti Scrum, l’Incremento, è una componente del prodotto (o del servizio) creata durante lo Sprint: può essere un componente software, un nuovo servizio o processo, una campagna di marketing, una nuova puntata di una serie TV, etc. Tutto dipende dal contesto in cui utilizziamo Scrum ma l’importante è che costituisca valore riconoscibile per il cliente.
Ogni Incremento è “additivo”, si aggiunge agli Incrementi realizzati in precedenza in un insieme verificato, coeso e perfettamente integrato e, poiché in Scrum l’Incremento ha lo scopo di fornire valore, ogni Incremento deve essere utilizzabile, funzionante e potenzialmente rilasciabile.
Come abbiamo visto:
- è possibile creare più Incrementi all’interno di uno Sprint ed è la loro somma ad essere oggetto di verifica (Inspect) durante la Sprint Review, supportando così quell’approccio empirico che abilita l’adattamento (Adapt)
- un Incremento può essere rilasciato prima della fine dello Sprint
- la Sprint Review non è un gate di fase o un OK formale al rilascio ma una occasione per raccogliere i feedback degli stakeholdere per decidere come evolvere il prodoto.
Per fare un esempio non tanto peregrino, se abbiamo completato lo sviluppo di un item ma non abbiamo effettuato tutti i test quell’item non rappresenta valore e non può far parte di un Incremento.
In Scrum il concetto di valore è binario: una cosa o è valore o non lo è. Il concetto di “Quasi completo” o il “Completo all’85%”) è un nonsense che non appartiene a Scrum.
Increment Commitment: Definition Of Done (DOD).
Per fare un esempio concreto, nel caso di un progetto di sviluppo software, la Definition Of Done conterrà tutti i criteri di qualità concordati traducibili, concretamente, nei diversi livelli di test da effettuare o nelle diverse attività da completare.
E’ una responsabilità dei Developer soddisfare la Definition of Done: è il loro impegno (Commitment) riguardo al lavoro necessario per completare un Incremento.La Definition of Done crea quel grado di trasparenza che riduce l’ambiguità e crea una comprensione condivisa di quale lavoro sia necessario perché un Incremento possa essere ritenuto completo (nelle vecchie versioni della Scrum Guide ci si riferiva alla Definition Of Done come “artefatto della trasparenza”).
Se, all’interno dell’organizzazione, esistono degli standard relativi alla qualità, la Definition of Done dovrà quantomeno considerarli come base di partenza, eventualmente da integrare. Diversamente, in assenza di standard organizzativi, lo Scrum Team avrà il compito di creare collaborativamente una Definition of Done adeguata al prodotto da realizzare.
Sotto trovi un esempio di quello che potresti trovare nella Definition Of Done (DOD):
Definition of Done (DOD)
Le nostre fonti
Lasciaci un commento
- E tu come gestisci gli Artefatti Scrum?
- Chi gestisce il Product Backlog?
- Chi ha la responsabilità dello Sprint Backlog?
- Che caratteristiche hanno i tuoi Incrementi?
- Come utilizzi la Definition of Done (DOD)
Mi piacerebbe davvero parlarne con te: che ne dici? Perchè non mi invii i tuoi commenti?
E, se hai voglia di approfondire, dai un’occhiata ai nostri corsi online o in aula/virtual-room.
Ti aspettiamo!
Stay agile! 🏄♀️
No Comments