scrum events time boxing
Introduzione agli eventi Scrum:
Nei nostri tutorial precedenti, abbiamo discusso di Scrum e di come è strutturato.
E il nostro precedente tutorial ha spiegato tutto su Manufatti di Scrum in dettaglio.
Sappiamo chi forma lo Scrum Team e quali diversi artefatti vengono sviluppati durante il processo. Ora abbiamo stabilito un solido background. Quindi, facciamo un passo avanti su Scrum e discutiamo gli eventi / cerimonie chiave che costituiscono lo Scrum Process.
In questo tutorial, proveremo a capire cosa significa ciascuno degli Scrum Event, quali sono le caratteristiche essenziali e come le organizziamo in dettaglio.
Cosa imparerai:
- Panoramica
- Tipi di eventi Scrum
- Cos'è il Time Boxing?
- Lo Sprint Planning
- The Daily Standup
- La Sprint Review
- La Sprint Retrospective
- Affinamento del backlog
- Conclusione
- Lettura consigliata
Panoramica
Mentre lavora a un progetto basato su Scrum, il team di Scrum esegue una serie di Cerimonie di Scrum.
Alcuni possono chiamarli cerimonie o eventi di Scrum e altri possono chiamarli per rituali o riunioni. Indipendentemente dalle diverse terminologie utilizzate qui, l'obiettivo di ogni evento Scrum rimane lo stesso. Ciascuno degli eventi Scrum, in sostanza, aiuta a realizzare e monitorare il lavoro dello Sprint.
Tipi di eventi Scrum
Ogni cerimonia Scrum è un incontro / incontro di persona organizzato dallo Scrum Master per i gruppi dedicati. Oltre al team principale, alcune riunioni possono coinvolgere le parti interessate, i responsabili delle consegne o persino il cliente stesso. Questi incontri sono a tempo determinato e quindi devono essere completati entro il periodo di tempo stabilito.
L'obiettivo di ogni riunione è riunire i partecipanti e lasciare che discutano del lavoro in corso. L'aspettativa di ogni partecipante è di rimanere concentrato, impegnato e partecipativo.
È considerata un'opportunità per conversare, esaminare e recuperare il feedback del lavoro svolto. A differenza degli incontri ordinari, gli eventi Scrum sono orientati ai risultati, time-boxed, basati sul pubblico di destinazione e hanno obiettivi specifici allineati con ciascuno di essi.
Cos'è il Time Boxing?
Il timeboxing è una delle caratteristiche chiave associate a ogni evento Scrum. I partecipanti sono tenuti a essere consapevoli e rispettosi del tempo assegnato a ciascuno degli eventi. Gli eventi non possono essere prolungati ma possono essere abbreviati se gli obiettivi dell'incontro sono già stati raggiunti.
Scrum Master, che è anche un facilitatore per tutti gli Scrum Events, si assicura che tutti comprendano l'importanza del time boxing e continua anche a ricordare loro di concentrarsi sull'obiettivo dell'incontro per ottenere i migliori risultati e in tempo con le deviazioni.
Il Timebox per un evento non dovrebbe idealmente essere esteso ma poiché sappiamo che lo Scrum non riguarda le regole, il tempo può essere esteso a una lunghezza particolare se ogni partecipante è d'accordo.
Come decidiamo il time box per ogni evento Scrum?
Il time box per gli eventi Scrum è direttamente proporzionale alla durata dello Sprint. Tuttavia, l'unica eccezione a questa regola è il Daily Standup che ha un intervallo di tempo fisso di 15 minuti indipendentemente dalla durata dello sprint.
Ci sono intervalli di tempo standard per ogni evento basati sulla durata dello Sprint. Tuttavia, il team ha la libertà di decidere i tempi per questi eventi in base alle proprie esigenze.
Comprendiamo più di questi concetti discutendo in dettaglio ogni evento Scrum.
Lo Sprint Planning
Come prerequisito per questa cerimonia, il Product Owner dovrebbe avere un Product Backlog stabile e prioritario di storie degli utenti preparato prima di partecipare alla riunione. Le storie degli utenti dovrebbero essere ben formate e abbastanza chiare da poter essere comprese dal team.
Il Product Owner può chiedere aiuto agli Stakeholder, al Cliente, al Designer e allo Scrum Master per sviluppare il Product Backlog.
È obbligatorio avere un criterio di accettazione in una User Story. Il team è autorizzato a rifiutare una user story senza i criteri di accettazione.
Scopo
Lo Sprint Planning è la cerimonia iniziale durante l'inizio di uno Sprint. Lo scopo dello Sprint Planning meeting è quello di creare uno Sprint Goal, selezionare le user story dal Product Backlog allo Sprint Backlog e discuterle in dettaglio.
Il team si riunisce in una sala riunioni insieme al Product Owner e allo Scrum Master dove il Product Owner presenta le user story che dovrebbero essere selezionate per lo sprint successivo.
Il team può porre tutte le domande che desidera per saperne di più sulla storia ed è responsabilità del Product Owner rispondere alle domande. Il team potrebbe anche sfidare la storia per la sua completezza e idoneità.
Se sono necessarie ulteriori informazioni all'interno della storia o ha una dipendenza incompleta o risulta incompleta, il team ha il potere di rifiutare quella storia.
Dopotutto, i dubbi sono stati chiariti e il team conosce la quantità esatta del lavoro che deve essere fatto per completare una storia, il team quindi stima e assegna i punti storia a ciascuna User Story.
In modo simile, le altre storie vengono discusse e valutate. Il team ora seleziona le storie dalla cima del Prioritized Product Backlog nello Sprint Backlog che pensano di essere in grado di impegnare e completare nello Sprint data la loro velocità passata.
La velocità è determinata dal numero totale di story point completati in uno sprint medio. La velocità viene calcolata in base agli Sprint storici e calcolandone la media. Più sprint completiamo, più stabile è la velocità per una squadra.
Molte squadre usano le carte Planning Poker per la stima della storia. La tecnica di stima più comune è indicare la storia utilizzando la serie di Fibonacci. La serie di Fibonacci è una serie di numeri in cui ogni numero successivo della serie è costituito dalla somma dei due numeri precedenti.
Serie di Fibonacci - 1, 1, 2, 3, 5, 8, 13 e così via.
Le user story stimate oltre i 13 story point sono considerate molto grandi da completare in un unico sprint e sono quindi scomposte in user story logiche più piccole che possono essere stimate individualmente.
Durante uno Sprint Planning Meeting, il team creerà anche attività sotto le user story che sono state selezionate per lo Sprint. Non ci si aspetta che il team incarichi tutte le user story durante lo Sprint Planning, ma è appena sufficiente per farle iniziare. Il resto del compito può essere svolto durante lo sprint.
Il risultato chiave di uno Sprint Planning meeting è lo Sprint Goal e lo Sprint Backlog, che consistono nelle user story che il team si è impegnato a completare.
Oltre alle User Story, possono esserci altri tipi di elementi che possono diventare parte dello Sprint Backlog.
- Spikes
- Debiti tecnici
- Bug
Spikes sono i compiti di ricerca per trovare una soluzione, ovvero la cui necessità è innescata dalla User Story stessa. Alcune delle storie potrebbero non essere semplici o non sono nella capacità tecnica e quindi richiederebbero più analisi e ricerche intorno ad esse. Pertanto viene creato un picco. Può anche includere un POC in caso di necessità.
Debiti tecnici sono il refactoring del codice esistente. Molte volte ci sono situazioni in cui il team deve rielaborare il codice sviluppato in precedenza per soddisfare i nuovi requisiti.
Bug in Scrum sono solitamente i requisiti nuovi o mancati che emergono dalle user story accettate ma sono rilevanti per gli elementi di lavoro correnti. Se non è un requisito, può effettivamente essere un bug nel sistema che è stato portato alla luce durante gli sprint precedenti ma non è stato risolto e ha avuto la priorità in questo sprint.
Partecipanti
Tutti nello Scrum Team fanno parte dello Sprint Planning meeting. Nessun altro oltre al team principale è invitato a partecipare alla riunione.
Lo Sprint Planning meeting è organizzato e facilitato dallo Scrum Master ma il Product Owner ruba la scena.
Time-box
Lo Sprint Planning meeting può richiedere fino a mezza giornata per uno Sprint di due settimane. Il time box per uno Sprint Planning meeting dipende direttamente dalla durata dello Sprint. Più corto per uno sprint breve e più lungo per uno sprint lungo.
Lo Sprint Planning meeting ha un ruolo cruciale nell'architettura Scrum complessiva e influenza direttamente il prodotto che viene sviluppato. Pertanto, il team dovrebbe investire tutto il tempo che ritiene necessario per discutere in dettaglio tutte le storie degli utenti e può proporre un time box alternativo adatto a loro.
Una volta deciso e concordato il time-box, è responsabilità dello Scrum Master mantenere il team concentrato sull'obiettivo e allo stesso tempo tenere traccia del tempo.
The Daily Standup
Scopo
Daily Standup è un incontro che offre l'opportunità di illustrare una visione generale della salute dello Sprint. È anche una piattaforma per discutere su cosa stanno lavorando gli altri membri del team e se c'è qualcosa che si ferma nel raggiungimento dell'obiettivo dello Sprint.
Durante una riunione quotidiana in piedi, ogni membro del team condivide lo stato dei suoi progressi sugli elementi di lavoro su cui sta lavorando. Potrebbero anche condividere e chiedere aiuto agli altri membri del team se ci sono ostacoli che bloccano i loro progressi.
Durante una riunione quotidiana in piedi, ogni membro del team attorno al tavolo risponde alle seguenti tre domande chiave una per una:
'Cosa hai fatto dall'ultima riunione quotidiana in piedi?'
'Cosa pensi di fare oggi?'
la migliore compagnia di giochi per cui lavorare
'C'è qualche impedimento che blocca il tuo lavoro?'
Ci si aspetta che gli altri membri del team prestino attenzione quando qualcuno condivide lo stato e si offrano aiuto in caso di necessità. Non appena l'ultimo membro del team ha risposto a tutte e tre le domande, l'incontro termina lì.
La riunione giornaliera in piedi fornisce un quadro generale di quale sia lo stato di completamento attuale e generale dell'iterazione su cui stanno attualmente lavorando. Lo Scrum Master gioca un ruolo molto importante nel mantenere il Daily Standup meeting mirato e con tempi precisi. È anche responsabile della risoluzione degli ostacoli che impediscono al team di progredire con le loro User Story.
Scrum Master deve anche assicurarsi che nessun altro al di fuori del core team faccia domande e presenti lo stato. Può consentire discussioni rapide sulle storie degli utenti, se necessario, ma deve rimanere consapevole del tempo per tutto il tempo e può in qualsiasi momento intervenire e chiedere ai membri del team di avere una discussione offline.
Partecipanti
Chiunque può partecipare a una riunione quotidiana in piedi. Tuttavia, è obbligatorio che il core team partecipi alla riunione e presenti lo stato del proprio lavoro.
Chiunque, anche al di fuori del team, che sia interessato a conoscere i progressi dello Sprint può partecipare al Daily Standup Meeting ma non è autorizzato a presentare lo stato del proprio lavoro o interrogare i membri del Team di Sviluppo sul loro lavoro.
Solo i membri del team principale possono condividere i loro progressi nel lavoro e tutti gli altri dovrebbero ascoltare in silenzio.
Il Daily Standup meeting dovrebbe essere condotto anche se è presente un solo membro del team.
Il team può condurre il Daily Standup Meeting da solo o può chiedere allo Scrum Master di facilitarlo per loro.
Time-box
Come suggerisce il nome, ogni giorno si svolge una riunione quotidiana in piedi e ci si aspetta che i partecipanti rimangano in piedi poiché si tratta di una riunione breve di soli 15 minuti. L'idea è di attenersi all'agenda e di non deviare il focus, quindi l'incontro è breve. Mantenere la riunione aiuta anche le persone a impegnarsi facilmente in quanto richiede solo 15 minuti.
Anche la riunione giornaliera in piedi viene tenuta alla stessa ora e nella stessa posizione ogni giorno per ridurre la confusione tra i partecipanti e le spese generali per prenotare le sale riunioni ogni giorno. L'uso di laptop, desktop o telefoni cellulari è fortemente sconsigliato durante la riunione.
Le squadre possono decidere quando tenere il Daily Standup meeting e rispettarlo. Tuttavia, la tendenza normale è di tenere le riunioni come prima cosa al mattino. Per i team che lavorano in fusi orari diversi, la chiamata mattutina potrebbe non funzionare e quindi possono avere la chiamata nel pomeriggio o qualunque cosa si adatti meglio a loro.
Lo Scrum Master potrebbe anche condividere le notizie o gli aggiornamenti importanti alla fine della riunione con il team se il tempo lo consente ma non è autorizzato a prolungare l'incontro a qualsiasi costo.
La Sprint Review
Scopo
Lo Sprint Review Meeting consiste nel dimostrare il lavoro svolto e raccogliere feedback e buy-in. In alcuni punti, lo Sprint Review meeting è noto anche come Sprint Demo. Lo Sprint Review Meeting viene solitamente svolto alla fine dello sprint ma prima dello Sprint Retrospective meeting.
Il / i rappresentante / i scelto / i dal team mostra gli elementi di lavoro correnti dello sprint. Di solito, lo sviluppatore che lavora sulla user story dimostra il lavoro e risponde alle domande sollevate da chiunque nel pubblico.
Le user story realizzate in base alla Definition of Done sono gli unici candidati per la dimostrazione allo Sprint Review Meeting.
Il Product Owner gioca un ruolo molto importante durante lo Sprint Review Meeting. È l'unico responsabile di valutare ciascuna user story dimostrata rispetto ai suoi criteri di accettazione e accetta o rifiuta la storia.
Le storie accettate vengono quindi integrate con Done Increment, che è un prodotto potenzialmente disponibile per la spedizione. Dove andrebbe a finire una storia rifiutata o incompleta è la chiamata del Product Owner. Le storie rifiutate possono diventare una parte dello sprint successivo o possono passare al Product Backlog da dove verranno nuovamente assegnate le priorità.
Il risultato chiave dello Sprint Review meeting è un quadro generale della data di completamento del progetto. Il Product Owner accetta / rifiuta la storia e le storie accettate vengono quindi integrate con l'Incremento (creato durante gli sprint precedenti) nel suo insieme per dare un'immagine migliore di dove ci troviamo nel completare l'intero prodotto.
Un altro risultato chiave della riunione di Sprint Review è che i membri del team imparano qualcosa sulla stima. Il numero di storie utente accettate determina il numero di story point raggiunti in uno sprint.
Quindi, gradualmente, sprint per sprint, il team può sviluppare la capacità di stimare correttamente e prendere una decisione informata riguardo ai punti della storia che è possibile ottenere.
Si osserva spesso che tali riunioni fanno luce sui criteri di accettazione incompleti o sui nuovi requisiti che emergono. Il modo migliore per affrontare questa situazione è chiudere le storie e contrassegnarle come completate se soddisfano tutti i Criteri di Accettazione inizialmente concordati durante lo Sprint Planning Meeting.
Qualsiasi cosa oltre a ciò deve essere considerata come un nuovo requisito e il Product Owner è responsabile di tali requisiti per lo sprint futuro.
Partecipanti
Allo Sprint Review Meeting partecipano i membri del team, inclusi lo Scrum Master e il Product Owner. Altri partecipanti allo Sprint Review Meeting sono gli stakeholder, i responsabili delle consegne, i clienti / utenti finali o chiunque sia interessato a far parte di Sprint Review.
Time-box
In uno scenario ideale per uno sprint di due settimane, trascorriamo circa 2 ore nello Sprint Review meeting. Questo può variare in base alla lunghezza dello Sprint. Per uno sprint più breve Sprint Review più breve e per uno sprint più lungo Sprint Review più lungo.
Come altri incontri, lo Scrum Master è responsabile di mantenere lo slancio dell'incontro e assicurarsi che le attività (dimostrazione delle storie, risposta alle domande, accettazione delle storie, feedback annotato ecc.) Rientrino nei tempi previsti.
La Sprint Retrospective
Scopo
Sprint Retrospective è incarnare ciò che dice Agile: ' Riflessioni regolari su come diventare più efficaci '. Sprint Retrospective offre all'intero team l'opportunità di riflettere e contemplare come è andato lo sprint e cosa deve essere fatto per improvvisare i processi? Sprint Retrospective viene eseguita alla fine di ogni sprint.
Durante uno Sprint Retrospective meeting, l'intero team si riunisce e discute lo Sprint che è stato appena completato. Il team dovrebbe essere trasparente e fornire opinioni oneste, ma non ci sono giochi di colpa.
Ricorda l'obiettivo dell'incontro di fare un passo avanti nell'area dell'improvvisazione e non tenere la squadra aumentando la tensione tra i membri.
Tutti nel il team dovrebbe rispondere alle quattro domande fondamentali:
Lo Scrum Master chiede ai membri del team di scrivere i loro punti per ciascuno dei quadranti come mostrato sopra in note adesive. In alcuni luoghi, gli strumenti vengono utilizzati per lo stesso scopo.
Cosa è andato bene?
come utilizzare team Foundation Server
I membri del team assegnano uno o più punti su quanto è andato bene nell'ultimo Sprint. Questa sezione può anche essere considerata un'opportunità per apprezzare e riconoscere gli altri membri del team per il loro buon lavoro.
Cosa hai imparato?
Scrum è considerato un'opportunità per imparare qualcosa di nuovo ad ogni sprint. Quest'area di un quadrante serve a discutere i punti chiave e gli apprendimenti dell'ultimo Sprint.
Cosa non è andato bene?
In questa sezione, il team discute i problemi e gli ostacoli che hanno dovuto affrontare durante l'ultimo sprint. Questa parte dell'incontro tende ad essere la più fragile in quanto le persone potrebbero sollevare questioni che potrebbero mettere a disagio gli altri.
È responsabilità dello Scrum Master calmare l'atmosfera, se necessario, e insegnare alle persone a sollevare i propri problemi in modo costruttivo invece di passare attraverso il giro di attacchi personali.
Se qualcuno dei membri si sente a disagio nell'affrontare i problemi di fronte agli altri compagni di squadra, può andare dallo Scrum Master in seguito e discutere i problemi.
Cosa si potrebbe fare di meglio?
Questa parte dell'incontro offre l'opportunità a tutti i membri del team di discutere tutte le questioni sollevate in precedenza e trovare i modi per risolverle. Tutti i membri del team sono invitati a proporre soluzioni al problema in questione. Il team decide quindi in unità le soluzioni più adatte.
Il team dovrebbe anche considerare di attenersi alle cose che sono state discusse nella sezione su ciò che è andato bene anche per gli sprint futuri e, andando avanti, queste cose possono essere aggiunte come parte integrante del processo.
Il risultato dello Sprint Retrospective meeting è un elenco di elementi di azione concordati dai partecipanti per migliorare il processo per il prossimo sprint.
Partecipanti
L'intero Scrum Team, inclusi lo Scrum Master e il Product Owner. Ma a differenza di una riunione quotidiana in piedi, lo Scrum Master e il Prodotto partecipano anche a fornire i loro input e punti retrospettivi.
Come il Daily Standup meeting, anche lo Sprint Retrospective meeting è facilitato dallo Scrum Master. Scrum Master si assicura che a tutti i membri del team, compreso se stesso, venga data l'opportunità di aprirsi e parlare sia degli aspetti positivi che negativi.
Prendi nota che i partecipanti al di fuori del team non sono invitati allo Sprint Retrospective Meeting. Sprint Retrospective è considerato un piccolo ambiente personale ed emotivo che consente ai membri del team di aprirsi senza esitazione e discutere i problemi che hanno affrontato durante l'ultimo sprint.
Time-box
Si dice giustamente che tutte le Cerimonie di Scrum sono time boxed e il loro time box dipende dalla durata dello Sprint. Detto questo, per uno sprint di due settimane, è l'ideale avere uno Sprint Retrospective meeting di 2 ore.
Tuttavia, se guardiamo alla Sprint Retrospective come un'opportunità per comunicare, ripensare e impegnarsi per i miglioramenti, è assolutamente giustificato dare abbastanza tempo per l'incontro per evitare di perdere punti di vista e intuizioni importanti.
Quindi è bene fissare un appuntamento per la riunione, ma non dovrebbe essere fatto a scapito della comunicazione e del progresso. Un altro evento molto importante in Scrum è il perfezionamento del backlog. Prendiamoci solo un momento per far luce su di esso.
Affinamento del backlog
Il perfezionamento del backlog, noto anche come pulizia del backlog, è un incontro per discutere le storie degli utenti nel Product Backlog che potrebbero essere una parte del prossimo Sprint. In una riunione di raffinamento del backlog, l'intero team si riunisce e discute le storie degli utenti fornendo così i loro input.
L'idea generale è preparare il Product Backlog per il prossimo Sprint e assicurarsi che le storie degli utenti siano pronte per essere selezionate. L'incontro di affinamento del backlog è organizzato durante lo sprint 'n-1' per preparare gli elementi da selezionare nello sprint 'n'.
Conclusione
Con questo, siamo giunti alla fine di questo tutorial sugli 'Eventi Scrum', che è un must per leggerne uno. Gli eventi Scrum sono di gran lunga l'argomento più importante e significativo della Scrum Series.
In questo tutorial, abbiamo discusso di tutti e cinque gli eventi Scrum, ovvero Sprint, Sprint Planning, Daily Standup, Sprint Review e Sprint Retrospective . Ogni evento diverso dallo standup giornaliero ha un ciclo regolare per sprint, ovvero eseguito una volta in ogni sprint.
Gli eventi danno un'idea di come le attività vengono svolte in un ambiente Scrum. Tutti gli eventi Scrum sono opportunità di miglioramento, adattamento e ispezione.
Il prossimo è il tutorial sul 'Triaging dei difetti' che è un incontro formale in cui tutti i difetti dell'attuale Sprint vengono discussi e valutati, ovvero prioritari.
Tutorial PREV | PROSSIMO Tutorial
Lettura consigliata
- Artefatti Scrum: Product Backlog, Sprint Backlog e Product Increment
- Tutorial JIRA Scrum Board: Gestione di Scrum con Jira per la gestione dello Sprint
- Quiz online su Agile Scrum: prova la tua conoscenza di Agile Scrum
- Come fornire funzionalità software di alto valore in un breve periodo di tempo utilizzando Agile Scrum Process
- Valutazione dei difetti in Scrum: come è organizzata in un setup di Scrum
- Opportunità di lavoro freelance part-time per esperti di selenio
- Ruoli e responsabilità dello Scrum Team: Scrum Master e Product Owner
- I 10 migliori software gratuiti per il rilevamento del tempo dei dipendenti