Lavori pianificati e non pianificati in Scrum
La maggior parte dei team che iniziano a lavorare con Scrum comprende il proprio Backlog e i cosiddetti „lavori pianificati”. Si tratta dei lavori che tutti hanno raccolto insieme e che hanno compreso a fondo. E poi c'è tutto il resto… Ecco a cosa devono prestare attenzione i nuovi Scrum Team nel loro primo Sprint. Tutti gli elementi che svolgono indipendentemente dai lavori pianificati per quello Sprint vengono elencati nella colonna „lavori non pianificati” con le ore necessarie.
Dopo il primo Sprint, i team sono spesso totalmente sorpresi da quanto si accumuli. Di solito si tratta di varie attività che si svolgono ogni giorno o ogni settimana da tempo immemorabile – le chiamiamo spesso task „Business-as-Usual” (BAU), ma in altre aziende possono avere altri nomi. Poi ci sono meeting ad hoc e altre cose che facciamo senza pensarci troppo. Possono essere task BAU o semplicemente disturbi o interruzioni.
Inoltre ci sono le emergenze che devono essere risolte immediatamente. Spesso rientrano nel „Support” – ma potrebbero avere qualsiasi altro nome.
Alcune di queste cose sono già note durante lo Sprint Planning. Allora le si aggiunge allo Sprint Backlog come parte dei commitment. Se si ripresentano regolarmente, potrebbe valere la pena creare una colonna dedicata e riservare una certa capacità per queste attività.
Cosa fare con i lavori non pianificati in Scrum?
Organizza un meeting per esaminare più da vicino i task ricorrenti e capire come migliorare il lavoro con essi. L'obiettivo è automatizzarli o almeno ridurli il più possibile.
Gli elementi che non si possono considerare nello Sprint Planning sono quelli che emergono durante lo Sprint e che non possono essere previsti. Li chiamiamo „unplanned” ovvero „non pianificati”. Ogni team ha alcuni di questi lavori non pianificati e deve capire come gestirli. Anche in questo caso, dovresti riflettere regolarmente su cosa puoi fare per ridurre il più possibile questi lavori non pianificati. Più lavoro non pianificato ha un team, meno lavoro aggiuntivo può essere preso in carico. Idealmente, la maggior parte del lavoro di uno Scrum Team dovrebbe essere lavoro pianificato. Ogni team deve valutare le proprie capacità e capire come lavorare al meglio.
Ecco alcuni dei metodi che ho già visto nei team:
Limiti e regole
Ogni lavoro non pianificato viene annotato sulla board e prioritizzato. Tuttavia, la colonna Work-in-Progress ha un limite di quanti lavori possono essere affrontati contemporaneamente, ad esempio due. Quindi si può lavorare solo su due cose diverse alla volta. Il resto del team può così concentrarsi sui lavori pianificati per lo Sprint. Si possono anche stabilire regole su quali elementi non pianificati possono essere scritti sulla board e quando ecc.
Una persona al giorno/settimana/Sprint
Si può anche creare un piano che stabilisca chi e quando è assegnato a lavorare sugli elementi non pianificati. Anche così il resto del team può concentrarsi sui lavori pianificati. Se la persona assegnata non capisce qualcosa o ha un problema, può chiedere aiuto agli altri membri del team. Si può alternare giornalmente, settimanalmente o ad ogni Sprint.
Una finestra temporale specifica
Si può anche stabilire una finestra temporale per i lavori non pianificati. Può essere ad esempio tra le 09:00 e le 11:00, il resto della giornata lavorativa è poi riservato agli elementi dello Sprint.
Giorni fissi
Si possono anche pianificare determinati giorni della settimana per i lavori non pianificati – ad es. martedì e giovedì. Tutti gli altri giorni lavorativi sono dedicati solo ai lavori pianificati.
Gli Scrum Team possono alternarsi
Se più Scrum Team lavorano sullo stesso Backlog, i team possono alternarsi nel gestire i lavori non pianificati. Il Team A lavora questo Sprint solo su elementi non pianificati e il Team B lavora sugli elementi del Backlog.
Avrai sicuramente notato che in tutti gli esempi ai team viene data una fascia temporale concreta per il lavoro sugli elementi del Backlog. Non esiste uno schema fisso e sicuramente ci sono più possibilità di quelle menzionate sopra. Se anche tu hai questo problema, prova semplicemente alcuni di questi suggerimenti e scopri cosa funziona meglio per te.
Questo testo proviene dal blog di Growing Agile ed è stato messo a nostra disposizione.
