La Scrum Guide 2020 definisce tre artefatti Scrum e a ciascuno è associato un impegno: il Product Backlog si impegna per il Product Goal, lo Sprint Backlog per lo Sprint Goal e l'Increment per la Definition of Done. Gli artefatti rendono trasparenti il lavoro e il valore, mentre gli impegni danno a ogni artefatto uno scopo chiaro rispetto al quale misurare i progressi. Se capisci queste tre coppie, sai rispondere a gran parte delle domande sugli artefatti agli esami PSM I, PSPO I e CSM.
Quali sono i tre artefatti Scrum?
Gli artefatti Scrum rappresentano lavoro o valore. Esistono per massimizzare la trasparenza delle informazioni chiave, in modo che chiunque li ispezioni abbia la stessa base per l'adattamento. Questo si collega direttamente ai tre pilastri di Scrum: trasparenza, ispezione e adattamento. Un artefatto non trasparente porta a decisioni sbagliate, perché non puoi ispezionare ciò che non vedi.
L'edizione 2020 della Scrum Guide ha aggiunto un impegno a ciascun artefatto. La Guida descrive questi impegni come strumenti che rafforzano l'empirismo e i valori di Scrum per lo Scrum Team e per i suoi stakeholders.
Artefatti e impegni Scrum in sintesi
| Artefatto | Impegno | Chi ne è responsabile |
|---|---|---|
| Product Backlog | Product Goal | Product Owner (gestione del Product Backlog, compresi lo sviluppo e la comunicazione del Product Goal) |
| Sprint Backlog | Sprint Goal | Developers (lo Sprint Backlog è il loro piano, fatto da loro e per loro) |
| Increment | Definition of Done | Gli Developers vi si conformano; lo Scrum Team la crea se l'organizzazione non ne fornisce una |
Tieni a mente questa tabella per l'esame. Molte domande trabocchetto si limitano a scambiare il responsabile di un artefatto o ad abbinare un artefatto all'impegno sbagliato.
Product Backlog e Product Goal
Il Product Backlog è un elenco emergente e ordinato di ciò che serve per migliorare il prodotto. È l'unica fonte del lavoro svolto dallo Scrum Team. Gli elementi in cima sono di solito più chiari e più raffinati, perché è probabile che vengano scelti nel prossimo Sprint Planning.
Il Product Backlog refinement è l'attività di scomporre gli elementi e aggiungere dettagli come descrizione, ordine e dimensione. È un'attività continua, non un evento Scrum. La Guida 2020 non indica una percentuale fissa; la vecchia linea guida del “non più del 10% della capacità degli Developers” è stata eliminata.
Il Product Owner è responsabile della gestione del Product Backlog. Il Product Owner è una persona, non un comitato. Può delegare ad altri il lavoro di scrivere o ordinare gli elementi, ma ne resta responsabile.
Che cos'è il Product Goal e perché è stato aggiunto nel 2020?
Il Product Goal descrive uno stato futuro del prodotto e serve come bersaglio rispetto al quale lo Scrum Team pianifica. È l'obiettivo a lungo termine dello Scrum Team, e il Product Backlog emerge per definire il “cosa” che lo realizzerà.
Prima del 2020, Scrum non aveva un obiettivo esplicito a livello di artefatto al di sopra dello Sprint Goal. I team potevano lavorare Sprint dopo Sprint senza una visione condivisa di dove stesse andando il prodotto. Il Product Goal colma questa lacuna: collega ogni Sprint Goal a uno scopo più ampio e dà agli stakeholders qualcosa di concreto rispetto a cui ispezionare i progressi.
Due dettagli contano per l'esame. Primo, lo Scrum Team lavora su un solo Product Goal alla volta. Secondo, deve realizzare (raggiungere) o abbandonare un Product Goal prima di passare al successivo.
Sprint Backlog e Sprint Goal
Lo Sprint Backlog è composto da tre parti: lo Sprint Goal (perché), l'insieme degli elementi del Product Backlog selezionati per lo Sprint (cosa) e un piano attuabile per realizzare l'Increment (come). Corrispondono ai tre argomenti dello Sprint Planning: perché questo Sprint è di valore, cosa si può completare (Done) in questo Sprint e come verrà svolto il lavoro scelto.
Lo Sprint Backlog è un piano fatto dagli Developers e per gli Developers. È una rappresentazione molto visibile, in tempo reale, del lavoro che gli Developers pianificano di svolgere durante lo Sprint. Gli Developers ne sono i proprietari e lo aggiornano durante tutto lo Sprint man mano che imparano di più.
Come lo Sprint Goal dà flessibilità
Lo Sprint Goal è l'unico obiettivo dello Sprint. Viene creato durante lo Sprint Planning e aggiunto allo Sprint Backlog. Pur essendo un impegno degli Developers, offre flessibilità sul lavoro esatto necessario per raggiungerlo.
In pratica, questo significa che gli elementi selezionati e il piano possono cambiare durante lo Sprint mentre l'obiettivo resta stabile. Se il lavoro si rivela diverso da quanto previsto, gli Developers collaborano con il Product Owner per negoziare l'ambito dello Sprint Backlog all'interno dello Sprint, senza cambiare lo Sprint Goal. Il Daily Scrum è il momento in cui gli Developers ispezionano i progressi verso lo Sprint Goal e adattano lo Sprint Backlog se necessario.
Se lo Sprint Goal stesso diventa obsoleto, solo il Product Owner può annullare lo Sprint.
Increment e Definition of Done
Un Increment è un passo concreto verso il Product Goal. Ogni Increment si aggiunge a tutti i precedenti ed è verificato a fondo, in modo che tutti gli Increment funzionino insieme. Per dare valore, l'Increment deve essere utilizzabile.
Cosa significa “Done”
La Definition of Done (DoD) è una descrizione formale dello stato dell'Increment quando soddisfa le misure di qualità richieste per il prodotto. Nel momento in cui un elemento del Product Backlog rispetta la Definition of Done, nasce un Increment.
La DoD crea trasparenza dando a tutti una comprensione condivisa di quale lavoro è stato completato come parte dell'Increment. È l'asticella della qualità, e gli Developers sono responsabili di infondere qualità rispettandola.
Da dove viene la Definition of Done:
- Se l'organizzazione ha una Definition of Done tra i propri standard, tutti gli Scrum Team devono seguirla come minimo.
- Se non ce l'ha, lo Scrum Team deve creare una Definition of Done adeguata al prodotto.
- Un team può rendere la propria DoD più severa dello standard dell'organizzazione, ma non più debole.
Cosa succede al lavoro non finito?
Se un elemento del Product Backlog non rispetta la Definition of Done, non può essere rilasciato e nemmeno presentato alla Sprint Review. Torna invece nel Product Backlog per essere valutato in futuro. In Scrum non esiste “quasi finito” o “finito al 90%”: il lavoro o è Done o non fa parte dell'Increment.
Più Increment per Sprint
Un malinteso comune è che uno Sprint produca esattamente un Increment alla fine. La Guida 2020 afferma che all'interno di uno Sprint possono essere creati più Increment. La Sprint Review non va mai considerata un cancello per il rilascio del valore: un Increment può essere consegnato agli stakeholders prima della fine dello Sprint. La somma degli Increment viene presentata alla Sprint Review.
Trappole d'esame più comuni sugli artefatti Scrum
Questi sono i punti su cui i candidati inciampano più spesso nei test di allenamento e negli esami veri:
- Di chi è lo Sprint Backlog? Degli Developers. Non del Product Owner e non dello Scrum Master. Il Product Owner è responsabile del Product Backlog.
- Lo Sprint Backlog può cambiare durante lo Sprint? Sì. Gli Developers lo aggiornano man mano che imparano di più, e l'ambito può essere chiarito e rinegoziato con il Product Owner. Ciò che non va compromesso è lo Sprint Goal o la qualità.
- Il team può abbassare la DoD dell'organizzazione? No. La Definition of Done dell'organizzazione è il minimo. Il team può aggiungere requisiti.
- Il burndown chart è un artefatto? No. Burndown chart, velocity, story point e user story non sono nella Scrum Guide. Sono pratiche complementari.
- C'è un solo Increment per Sprint? Non necessariamente. Più Increment possono essere creati, e rilasciati, all'interno dello stesso Sprint.
- Si può mostrare il lavoro non finito alla Sprint Review? No. Torna nel Product Backlog.
- Quanti Product Goal alla volta? Uno. Deve essere realizzato o abbandonato prima del successivo.
Il modo migliore per verificare di conoscere davvero queste regole è rispondere a domande in stile esame sotto pressione di tempo. Prova la simulazione gratuita dell'esame PSM (20 domande, 20 minuti) oppure, se ti prepari all'esame Product Owner, il corso di preparazione alla certificazione Product Owner, dove le domande sul Product Goal e sulla gestione del Product Backlog compaiono spesso.
FAQ
Quali sono i 3 artefatti di Scrum?
Il Product Backlog, lo Sprint Backlog e l'Increment. Nella Scrum Guide 2020, ciascuno ha un impegno: rispettivamente il Product Goal, lo Sprint Goal e la Definition of Done.
Chi crea la Definition of Done?
Se l'organizzazione ha una Definition of Done, gli Scrum Team la seguono come minimo. Altrimenti, lo Scrum Team ne crea una adeguata al prodotto.
Lo Sprint Backlog può cambiare durante lo Sprint?
Sì. Gli Developers sono i proprietari dello Sprint Backlog e lo aggiornano durante tutto lo Sprint man mano che imparano di più. Lo Sprint Goal resta fisso e l'ambito può essere rinegoziato con il Product Owner.
Il Product Goal è un artefatto?
No. Il Product Goal è l'impegno dell'artefatto Product Backlog. È l'obiettivo a lungo termine dello Scrum Team, e il team ne persegue uno alla volta.