---

Impara Scrum con un caso di studio reale! Potrebbe sorprenderti!

Prima di iniziare il primo Sprint

Alex è lo Scrum Product Owner di un nuovo progetto software. Uno dei primi compiti è valutare e individuare i requisiti per fornire il valore aziendale cercato dal cliente.

Deve assicurarsi che il cliente riceva il software giusto per ottenere risultati aziendali tangibili. Scrive i casi d'uso essenziali e ne discute con architetti, rappresentanti dei clienti e altri stakeholder IT e aziendali. (Vedi la nostra Esempio Scrum)

Dopo aver raccolto casi d'uso e requisiti generali, li scrive nello Product Backlog Scrum e avvia con lo Scrum Team una sessione di stima e priorità. Tutti gli elementi dello Scrum Product Backlog ricevono così una prima stima approssimativa e una priorità.

Durante le sessioni, Anna, Scrum Master, assicura che tutti parlino la stessa lingua. Scrum Product Owner, membri del team e stakeholder sono così allineati agli obiettivi previsti. Hanno quindi una comprensione adeguata dei concetti potenzialmente nuovi per loro, come caso d'uso, backlog e Sprint. E soprattutto, il processo Scrum di sviluppo e consegna software viene applicato correttamente sul lavoro.

Alex inizia ora a suddividere i requisiti generali in una prima bozza di user story più dettagliate. Con questo elenco convoca il primo Sprint Planning.

Sprint 1 - Giorno 0

Durante lo Sprint Planning, Alex presenta gli elementi dello Scrum Product Backlog dalla priorità più alta alla più bassa. Il team pone domande e chiarisce dubbi. Per ciascuno discute capacità e competenze necessarie a svilupparlo e consegnarlo. Deve assicurare che tutte le risorse umane e tecniche necessarie siano disponibili prima dello Sprint. Deve confermare prerequisiti e dipendenze potenzialmente cruciali per consegnare con successo determinate funzionalità.

Durante lo Sprint Planning (parte sul che cosa), i Developer prevedono di completare le user story 1,2,3,6,7 e 8 entro la fine, a sostegno dello Sprint Goal concordato. Le storie vengono quindi spostate dallo Scrum Product Backlog allo Sprint Backlog. Le user story 4 e 5 non sono realizzabili in questo Sprint perché manca ancora parte dell'infrastruttura tecnica necessaria.

Dopo la parte sul che cosa, Anna invita lo Scrum Team ad approfondire come implementare le user story concordate (parte sul come). Le attività emerse vengono scritte su schede e inserite nello Sprint Backlog. Ora tutti sono pronti a scegliere un'attività e iniziare.

Sprint 1 - Giorno 1

Al mattino, i Developer si riuniscono per il Daily Scrum. Ciascuno fornisce una dichiarazione breve e concisa su ciò che ha fatto e aggiorna le stime del lavoro rimanente sulle schede dello Sprint Backlog. Spiega ciò che intende fare oggi e segnala eventuali impedimenti al lavoro.

Oggi Melinda informa il team di un problema con la licenza dell'ambiente integrato di sviluppo che usa. Anna verifica se anche gli altri lo incontrano e conferma che se ne occuperà dopo l'incontro. Dopo circa 15 minuti di Daily Scrum, tutti tornano al lavoro.

Dopo l'incontro, Anna aggiorna il Burndown dello Sprint per visualizzare l'avanzamento. Poi chiama il fornitore software, ordina la licenza mancante e la consegna a Melinda.

Introduzione a Scrum: un esempio reale (caso di studio) attraverso fasi e Sprint

Sprint 1 - Giorno 2

Al mattino, i Developer si riuniscono di nuovo per il Daily Scrum. Nel pomeriggio James ha dubbi sul risultato atteso di una user story. Chiama Alex, Scrum Product Owner, e ne discutono per assicurare la corretta comprensione. Quando James è sicuro di come procedere, continua l'implementazione.

Sprint 1: giorno 6

La giornata inizia con il Daily Scrum. Anna nota che questa mattina tende a superare 15 minuti: i membri discutono l'ottimizzazione di alcune query del database. Ricorda che i Daily Scrum non sono pensati per lunghe discussioni tecniche, ma per verificare l'avanzamento verso lo Sprint Goal e adattare il piano dei Developer.

Dopo il Daily Scrum, Alex (Product Owner) informa Anna (Scrum Master) di nuovi requisiti del cliente che potrebbero incidere sullo Sprint in corso e su quelli successivi. Anna gli ricorda gentilmente che i cambiamenti non devono mettere a rischio lo Sprint Goal. Developer e Product Owner possono chiarire o rinegoziare l'ambito man mano che imparano, senza considerare ogni storia selezionata un impegno immutabile. Anna organizza quindi un incontro di affinamento del backlog nel pomeriggio perché Alex presenti i nuovi requisiti al team.

Durante l'incontro, il gruppo aiuta Alex a capire dove collocare le user story nel piano complessivo, con prima suddivisione delle attività, stime e priorità.

Sprint 1: giorno 10

È finalmente l'ultimo giorno del primo Sprint. Anna invita lo Scrum Team alla Sprint Review. Il team ha preparato un server non di produzione con l'ultima versione dell'incremento software rilasciabile realizzato.

Alex e il signor Rich, stakeholder del cliente, si siedono davanti all'interfaccia grafica del software. Verificano se l'implementazione soddisfi le aspettative e se il team abbia documentato adeguatamente i dettagli del livello attuale dell'applicazione.

Alla fine della Sprint Review, Alex conclude:

• Il team ha consegnato le user story 1,2,6 e 7 come concordato e previsto.
• Non ha finito in tempo la user story 3 e non l'ha dimostrata. La storia incompiuta torna nel Product Backlog per riordinarla; il lavoro rimanente potrà essere selezionato nel prossimo Sprint Planning.
• La user story 8 non soddisfa la Definition of Done (DoD) comune. Torna nel Product Backlog, dove si possono chiarire criteri di accettazione e attività rimanenti prima di decidere quando selezionarla di nuovo.

Alex e il signor Rich, stakeholder del cliente, aggiornano brevemente lo Scrum Team sui cambiamenti imminenti e sulle difficoltà dei requisiti e sulla direzione della strategia complessiva del software. Il signor Rich ringrazia il team per impegno e sforzi e lascia la stanza.

Conclusa la Sprint Review, il team si riunisce per la Riunione di retrospettiva dello Sprint. Discutono ciò che è andato bene e ciò che si può migliorare, per affinare le previsioni ed evitare che negli Sprint successivi si ripetano i problemi delle user story 3 e 8. Una difficoltà individuata è la conoscenza insufficiente dell'architettura complessiva. Anna si assume il compito di coinvolgere un architetto di sistema per affiancare e guidare il team all'inizio dello Sprint successivo.

Sprint 2 - Giorno 1

Alex continua ad aggiungere requisiti allo Scrum Product Backlog dopo gli incontri con i clienti. Chiarisce inoltre criteri di accettazione e lavoro rimanente della user story 8, mantenendo la Definition of Done comune, perché il team possa immaginarne meglio il risultato atteso.

Invita poi il team allo Sprint Planning dello Sprint 2. Lo Scrum Team concorda uno Sprint Goal e i Developer selezionano e pianificano le user story a sostegno. Anna aiuta a rendere efficace l'evento e inizia il secondo Sprint.