Clicca l’immagine per ascoltare l’episodio del Podcast
Un Increment è un primo passo concreto verso il Product Goal ed è l’ultima versione del prodotto. È utilizzabile e potenzialmente pubblicabile in produzione.
Un Increment fornisce valore agli utilizzatori del prodotto.
Durante uno Sprint è possibile creare più Incrementi e potenzialmente rilasciarli durante lo Sprint, la somma degli incrementi viene ispezionata durante la Sprint Review. Il lavoro può essere considerato parte di un incremento solo se soddisfa la definizione di Done.
Le Basi di Scrum – Artefatti Scrum: Increment
Commitment: Definizione di Done
La Definizione di Done è una descrizione formale dello stato dell’Incremento quando soddisfa le misure di qualità richieste per il prodotto.
La definizione di Done crea trasparenza consentendo a tutti di comprendere il lavoro svolto nel contesto dell’Increment.
Se la definizione di fatto fa parte degli standard dell’organizzazione, tutti gli Scrum Team devono seguirla, eventualmente arricchendola. In caso contrario, lo Scrum Team deve creare una definizione appropriata di Done per il prodotto.
I Developers sono tenuti a rispettare la definizione di Done. Se più team Scrum lavorano insieme su un prodotto, devono definire una definizione di Done unica che prenda in considerazione le problematiche di integrazione.
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
Lo Sprint Backlog è un artefatto costituito dallo Sprint Goal (perché fare lo Sprint?), da tutti gli elementi del Product Backlog scelto per lo Sprint (cosa fare in questo Sprint?), nonché da un piano d’azione per la realizzazione dell’Incremento (come fare a creare valore in questo Sprint?).
Lo Sprint Backlogè un piano sviluppato dalle persone che faranno il lavoro, i Developers. Fornisce informazioni trasparenti, in ogni momento, sul lavoro svolto e ancora da fare per raggiungere lo Sprint Goal.
Clicca l’immagine per ascoltare il Podcast
Di conseguenza, lo Sprint Backlog viene aggiornato durante lo Sprint in base a ciò che lo Scrum Team impara.
Lo Sprint Backlog è un artefatto che viene creato durante lo Sprint Planning. Il suo contenuto tecnico, definito dai Developers, emerge durante lo Sprint grazie all’esperienza e alle nuove informazioni acquisite. L’emergere di nuove informazioni può avere un impatto sulle previsioni iniziali fatte dai Developers, che si impegnano a realizzare lo Sprint Goal. Si accetterà che la quantità di lavoro sia più o meno importante secondo gli Sprint perché in un mondo complesso e imprevedibile, le informazioni e le contingenze non sono mai congelate e conosciute in anticipo.
Le Basi di Scrum – Artefatti Scrum: Sprint Backlog
ENGAGEMENT: Sprint Goal
Lo Sprint Goal è l’unico obiettivo dello Sprint. Offre una certa flessibilità in termini di lavoro necessario per raggiungere questo obiettivo.
Lo Sprint Goal viene creato durante lo Sprint Planning e visibile nello Sprint Backlog, è immutabile per tutta la durata dello Sprint.
Se, a seguito dell’emergere di nuove informazioni, il contenuto dello Sprint deve essere modificato, gli sviluppatori lavorano con Product Owner per modificare il perimetro dello Sprint Backlog senza che questo modifichi lo Sprint Goal.
Nella tabella qui sotto ho riportato due esempi di Sprint Goal, abbastanza frequenti sul lato non accettabile
Sprint Goal Accettabile
Sprint Goal non accettabile
Essere in grado di autenticarsi sul sito Web
Correggere l’anomalia #34, #356-implementare l’accesso con Google – Se c’è tempo per correggere l’anomalia #234 (troppo dettagliato e rigido, lo Sprint Goal corrisponde a una quantità di lavoro da fare)
Mostrare i migliori prodotti nella home page
Mostrare i nostri migliori prodotti e fare in modo che la campagna marketing XY possa partire in tempo (due Sprint Goal distinti invece di uno unico)
Esempi di Sprint Goal
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
Clicca l’immagine per ascoltare l’episodio del Podcast
Ogni prodotto ha un solo Product Backlog, è in continua evoluzione grazie al feedback constante degli stakeholder e alle Sprint Review, gestito da un solo Product Owner.
Per rendere trasparente il Product Backlog, il Product Owner garantirà, tra le altre cose:
Un ordine e una priorità nel contenuto: in modo tale da rispecchiare la sua visione
Accessibilità al contenuto a tutto lo Scrum Team (e alle persone che lo richiedono in azienda)
La comprensione condivisa del suo contenuto. Spesso, ad esempio, ogni elemento del Product Backlog avrà le seguenti informazioni: un titolo, una descrizione, criteri di accettazione, un valore aziendale, una stima della complessità.
Le Basi di Scrum – Artefatti Scrum: il Product Backlog
commitment: PRODUCT GOAL
Il Product Goal descrive uno stato futuro del prodotto che può servire come destinazione per lo Scrum Team durante la pianificazione. Il Product Goal è visibile nel Product Backlog, è un obiettivo a lungo termine dello Scrum Team. Esiste un solo Product Goal in Scrum. Una volta raggiunto questo obiettivo ne verrà creato uno nuovo.
Clicca l’immagine per ascoltare l’episodio del Podcast
ADATTAMENTO DEL PRODUCT BACKLOG
Questo è fondamentale per massimizzare il valore del prodotto, ma cos’è esattamente questo adattamento?
Ridare un ordine e una priorità ai contenuti, a seguito del feedback degli stakeholder in Sprint Review e di continuo
Aggiunta di nuove idee
Rimozione di idee obsolete che non si adattano più al Product Goal (e quindi non hanno più valore)
Qualsiasi altra azione che renda il Product Backlog ordinato correttamente
IL VALORE È L’UNICO CRITERIO PER ORDINARE IL BACKLOG DEL PRODOTTO?
No. In effetti, il valore è un concetto soggettivo. Il Product Owner ordina il Product Backlog interagendo con gli Stakeholder. Altri parametri da considerare per ordinare il Product Backlog sono:
Valore aziendale: il problema più urgente per gli utenti, un vincolo normativo, una funzionalità che nessun concorrente possiede, ecc.
Il rischio: in Scrum il rischio non viene gestito, viene trattato per primo. Ciò ha un impatto sulla pianificazione
La dimensione degli elementi del Product Backlog: gli elementi importanti e di valore superiore avranno una dimensione giudicata dai Developers realizzabile in uno Sprint
In nessun caso l’ordine è dettato dalla difficoltà di realizzazione. Il Product Owner tiene conto dell’opinione dei Developers, senza concentrarsi prima sul “facile da fare”, perché questo non corrisponde a massimizzare il valore.
QUALE LIVELLO DI DETTAGLIO DOVREBBE AVERE UN ELEMENTO DEL Product BACKLOG
Un livello sufficiente per consentire a tutti di comprendere e ricordare l’argomento da discutere, quando sarà il momento.
Lettura consigliata: Agile Estimating and Planning
Ricorda uno dei quattro principi del Manifesto Agile: “gli individui e le interazioni più che i processi e gli strumenti”. Un elemento del Product Backlog, inizialmente, serve per contrassegnare l’idea non appena arriva e poi svilupparla quando diventa una “priorità”.
Non c’è bisogno di passare ore a scrivere specifiche dettagliate, in quanto si tratterebbe di una perdita di tempo ed energia che potrebbe essere dedicata ad argomenti di immediato valore per gli utenti.
L’attenzione si concentrerà sulla cooperazione di tutte le persone pertinenti sull’argomento al momento opportuno.
Vuoi andare oltre nella stima e nella pianificazione Agile? Il libro di Mike Cohn “Agile Estimating and Planning” è un buon inizio.
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
Per fornire le migliori esperienze, utilizziamo tecnologie come i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Il consenso a queste tecnologie ci permetterà di elaborare dati come il comportamento di navigazione o ID unici su questo sito. Non acconsentire o ritirare il consenso può influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici anonimi. Senza un mandato di comparizione, una conformità volontaria da parte del vostro Fornitore di Servizi Internet, o ulteriori registrazioni da parte di terzi, le informazioni memorizzate o recuperate per questo scopo da sole non possono di solito essere utilizzate per l'identificazione.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.
