Il Team di Sviluppo crea un nuovo Sprint Backlog durante la Pianificazione dello Sprint. Da quel momento in poi, diventa l’impegno attuale per gli Sviluppatori, ovvero un elenco di nuove funzionalità, miglioramenti e modifiche al Prodotto da implementare nello Sprint iniziale. Dopo l’inizio di uno Sprint, il Backlog diventa una coda vincolante dalla quale gli Sviluppatori scelgono i compiti da svolgere.
Uno Sprint Backlog descrive il lavoro del Team di Sviluppo durante un singolo Sprint. Pertanto, è espresso in linguaggio tecnico. Descrive compiti dettagliati e le loro soluzioni pianificate. Così, consiste in un elenco di compiti redatto in modo chiaro per gli Sviluppatori. Lo Sprint Backlog tiene solitamente poco conto del linguaggio del valore commerciale del Prodotto, un modo di descrizione proprio del Product Backlog, che introdurremo qui.
Lo Sprint Backlog nasce:
Durante la Pianificazione dello Sprint, il Product Owner propone come aggiungere valore al Prodotto nel prossimo Sprint. Poi l’intero Team Scrum lavora insieme per formulare l’Obiettivo dello Sprint, ovvero seleziona quale funzionalità del Product Backlog implementare. L’Obiettivo dello Sprint definisce come implementare il Prodotto o posticipare la scadenza per soddisfare le aspettative del Cliente.
Il passo successivo è riflettere e impostare realisticamente l’ambito di lavoro da svolgere nel prossimo Sprint e come raggiungerlo.
I risultati di queste riflessioni arrivano sotto forma di una descrizione tecnica dei compiti da svolgere. E questo elenco diventa il nuovo Sprint Backlog.
Il nuovo Sprint Backlog esiste in un luogo facilmente accessibile a tutti i membri del Team di Sviluppo. Nello spazio fisico, di solito è una lavagna appesa nello spazio di lavoro. Mentre nello spazio digitale, esiste come un documento condiviso basato su cloud che tutti gli Sviluppatori possono aggiornare. Anche se ogni membro di un Team Scrum dovrebbe tenerlo aggiornato quotidianamente, è il Scrum Master o uno degli Sviluppatori che di solito si assume quella responsabilità.
Il Product Backlog non specifica come eseguire esattamente i compiti. È compito del Team di Sviluppo decidere. Questa mossa crea abbastanza spazio per il team per manovrare, migliorando così le sue capacità di auto-organizzazione. Inoltre, questa libertà di selezionare la sequenza e i metodi di azione conferisce ad ogni Sviluppatore un senso di indipendenza e responsabilità.
La stessa idea si applica a considerare lo Sprint Backlog come un elenco non ordinato di compiti da eseguire. Contrariamente al modello tradizionale push (dove il Team o l’Sviluppatore agisce secondo un’agenda predefinita e imposta), nel modello pull, gli Sviluppatori selezionano quali compiti svolgere (modello pull).
Lo Sprint Backlog specifica:
Vari strumenti metrici riflettono il progresso del lavoro scritto nello Sprint Backlog. Più spesso è il Burndown Chart, che tratteremo completamente in un articolo dedicato. Con tale visualizzazione, il Team di Sviluppo può facilmente vedere se il lavoro sull’Obiettivo dello Sprint sta procedendo secondo i piani.
Può succedere durante uno Sprint che si scopra che il piano di lavoro è stato progettato in modo irrealistico. In altre parole, il numero di cose da fare nell’Obiettivo del Product Backlog è troppo alto o troppo basso. In entrambi i casi, gli Sviluppatori e il Product Owner si mettono al lavoro per scoprire quali cambiamenti applicare all’attuale Sprint Backlog. È possibile ridurre la quantità di lavoro, selezionare compiti aggiuntivi dal Product Backlog o estendere le soluzioni già pianificate. Tuttavia, tieni presente che l’Obiettivo dello Sprint stesso deve rimanere invariato.
Uno Sprint Backlog è un elenco di compiti che gli Sviluppatori pianificano di svolgere durante uno Sprint. È una sorta di contratto dettagliato con il Product Owner. Lo Sprint Backlog nasce durante la Pianificazione dello Sprint a cui partecipa l’intero Team Scrum. Il Burndown Chart riflette il grado di completamento dei compiti accettati per l’implementazione.
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
Diverse eventi più piccoli compongono uno Sprint in Scrum. Gli Sprint, a loro volta, formano…
I destinatari sempre più spesso si rivolgono ai materiali video. Le forme scritte diventano meno…
La scrittura pubblicitaria è diventata una professione estremamente popolare negli ultimi tempi. Ci sono sempre…
Hai mai la sensazione che la giornata sia troppo corta per fare tutto ciò che…
Che cos'è il software? Quali sono i tipi e i metodi di distribuzione? Rimanendo in…
Presentare e comunicare i risultati della ricerca è probabilmente una delle abilità più cruciali (e…