IT 
EN 
JA 
ES 
La pietrificazione della pianificazione
I risultati del tuo Sprint Planning sono predeterminati? L'incontro sembra stereotipato? O anche solo decisamente noioso? Se è così, la tua squadra ha raggiunto quella che io chiamo la "pietrificazione della pianificazione". L'incontro ha raggiunto un punto in cui la flessibilità e la creatività offerte attraverso di esso sono diminuite. È pietrificato. Potrebbe anche aver raggiunto il punto di avere un impatto negativo sulla squadra... ma non tutto è perduto! Se la formazione dello Sprint Backlog è diventata un'impostazione per il tuo team per "firmare" una serie rigida di requisiti, allora dubito che si stiano muovendo verso il diventare un team auto-organizzato. Non appena hanno smesso di considerare lo Sprint Backlog come un'unità di lavoro coesa, allora l'incremento stesso risultante sarà probabilmente percepito come 'piccolo' – privo di valore. C'è del bello da vedere allo Sprint Planning meeting, basta saperlo svelare.
Fondamentalmente, lo scopo dello Sprint Planning è produrre due cose. In primo luogo, uno Sprint Goal, lo scopo unificato dell'intero incremento. È il palo della porta verso cui la squadra dovrebbe muoversi. Dovrebbe essere misurabile, realizzabile, fisso e, soprattutto, consentire la creatività nel modo in cui viene raggiunto. In secondo luogo, lo Sprint Backlog stesso: il probabile lavoro necessario per raggiungere l'obiettivo. Si noti che ho usato la parola "probabile" - un malinteso comune in Scrum è che il team si stia impegnando a "finire" lo Sprint Backlog. In realtà, si impegnano a raggiungere lo Sprint Goal. Questa è una distinzione importante: il team può adattare il proprio approccio in base all'ispezione dei progressi ('Rispondere al cambiamento seguendo un piano' suona qualche campanello?).
Ecco una tecnica che ti propongo di provare. Funziona per costruire l'autorganizzazione, la creatività e concentrarsi sullo scopo collettivo. È importante sottolineare che richiede fiducia.
Supponiamo che tutto lo Scrum Team sia presente e che tu abbia un Product Backlog ben ordinato che il team ha perfezionato nel tempo. Il Product Owner sa cosa vuole ottenere.
Passo 1: Butta via il Product Backlog (metaforicamente). Informa il team che non utilizzerai il Product Backlog per guidare la riunione di pianificazione.
Passo 2: Chiedi al Product Owner di definire chiaramente il valore che desidera dal prossimo Sprint (in particolare non facendo riferimento ai ticket).
Passaggio 3: Il Team di Sviluppo, in collaborazione con il Product Owner, definisce ticket e criteri di accettazione per il lavoro iniziale verso lo Sprint Goal. Non stanno ancora guardando il Product Backlog.
Cosa ottiene questo approccio? Stai rimuovendo la stampella del Product Backlog. Considerano il lavoro pianificato come un incremento formato piuttosto che una raccolta di biglietti individuali. Stanno collaborando e non firmano. Hanno il potere di essere creativi e di impegnarsi. In breve, accettano il valore dello Sprint Goal. Ricorda, però, di rivisitare sempre il Product Backlog alla fine della sessione per rivedere il tuo approccio – non dimenticare che è ancora l'artefatto principale che guida l'evento.
Per me, anche se la Sprint Review è il luogo in cui si misurano i progressi complessivi, è la riunione di pianificazione che amo. Perché? Perché è il punto in cui riesco a vedere quanto sia entusiasta la mia squadra per la sfida imminente. Dopotutto, se non hanno il fuoco nella pancia alla linea di partenza, come pensi che si sentiranno al traguardo quando non volevano nemmeno essere in gara?