5 – Eventi Scrum: Sprint Planning

Eventi Scrum: Sprint Planning. Lo Sprint Planning è il primo evento dello Sprint. Il suo obiettivo è quello di collaborare alla pianificazione del lavoro da fare durante lo Sprint. Ha un timebox di 8 ore per uno Sprint di un mese, proporzionalmente meno per uno Sprint più breve. L’intero Scrum Team partecipa per tutta la durata.

I tre argomenti seguenti vengono discussi durante lo Sprint Planning.

1 – PERCHÉ QUESTO SPRINT È IMPORTANTE?

Il Product Owner propone come il prodotto potrebbe aumentare il valore e l’utilità durante l’attuale Sprint.

La parte superiore del Product Backlog sarà costituita da elementi abbastanza piccoli, conosciuti e compresi dall’intero Scrum Team e coerenti con la visione del Product Owner.

Lo Scrum Team lavora insieme per definire uno Sprint Goal realistico e realizzabile per la fine dello Sprint.

2 – COSA POSSIAMO FARE in questo SPRINT?

I Developers selezionano gli elementi del Product Backlog realizzabili in uno Sprint, collaborando con Product Owner. 

Alcuni fattori hanno un impatto sulle stime dei Developers, come: 

  • Definizione di Done 
  • Prestazioni passate
  • Azioni di miglioramento da implementare
  • La capacità dello Scrum Team (ferie, assenze varie, assegnazioni parziali).

3 – COME VERRÀ SVOLTO IL LAVORO SCELTO?

Per ogni elemento del Product Backlog (non necessariamente tutti), gli sviluppatori pianificano il lavoro necessario per creare un incremento che soddisfi la definizione di Done, con più o meno dettagli a seconda dell’esperienza.

Lo Sprint Goal, gli elementi del Product Backlog per lo Sprint, così come il piano per consegnarli costituiscono lo Sprint Backlog. Accetteremo che lo Sprint Backlog cambi in base alle informazioni che emergono durante lo Sprint.

OSSERVAZIONI IMPORTANTI

  • In un contesto complesso, come lo sviluppo software, le interazioni non sono mai lineari. Aspettatevi che tutti e tre gli argomenti siano ridiscussi più volte durante lo Sprint Planning.
  • L’unico commitment preso dallo Scrum Team è il raggiungimento dello Sprint Goal. Non è la quantità di lavoro, o gli elementi del Product Backlog sviluppato alla fine dello Sprint che conta, è il fatto che lo Scrum Team sia riuscito a raggiungere lo Sprint Goal e a creare un incremento Done potenzialmente rilasciabile in produzione. Anche il più piccolo.
  • Da “Push” a “Pull”: solo i Developers possono fare previsioni su quanti elementi del Product Backlog verranno realizzati durante lo Sprint. Si dice che i Developers “tirano” il lavoro da fare in base ai suggerimenti del Product Owner. Nessuno può imporre loro o “spingere” una quantità di lavoro da fare. Rinunciare ad accettare questo modo di lavorare significa depotenziare i Developers e spesso porta ad effetti collaterali come: mancanza di commitment, mancanza di qualità, debito tecnico, turnover, ecc.
  • I Developers selezioneranno gli elementi del Product Backlog nell’ordine definito dal Product Owner.  Non si sceglie l’elemento più facile da raggiungere, per comodità.
  • Il Product Owner partecipa e collabora alle discussioni sull’argomento “3 – Come verrà svolto il lavoro scelto?”.  Sì! Rimane per il motivo indicato nel primo punto di questa lista. Ci si deve sempre aspettare interazioni non lineari all’interno dello Scrum Team durante lo Sprint Planning.
  • Lo Sprint Backlog non necessità dettagli in tutti i suoi contenuti. L’importante sarà avere abbastanza dettagli per poter avviare lo Sprint. Si accetterà l’emergere del lavoro durante lo Sprint (e le modifiche conseguenti allo Sprint Backlog).

Al termine dello Sprint Planning, lo Sprint Goal, le previsioni degli elementi del Product Backlog  da sviluppare (realizzati dai Developers) e il piano per raggiungerli saranno tutti elementi visibili nello Sprint Backlog.

Le Basi di Scrum - Eventi Scrum: Sprint Planning
Le Basi di Scrum – Eventi Scrum: Sprint Planning

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 la conoscenza del framework Scrum!

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.

Tradotto dal francese da Denise Monreale, grazie!