Cos'è una riunione di pianificazione degli sprint?
I team di sviluppo software si affidano agli sprint per tenere il passo con il lancio di nuove versioni del software, chiamate iterazioni. Date le richieste contrastanti su cosa includere in un'iterazione, il team di sviluppo deve essere molto chiaro sugli aspetti su cui dovrebbe concentrarsi durante uno sprint: ad esempio, alcune correzioni di bug dovrebbero avere la precedenza sul lancio di nuove funzionalità o viceversa?
Agile è diventato popolare anche in altri campi e settori perché questo approccio mirato può aumentare l'efficacia, la produttività e la qualità.
Prima di iniziare uno sprint, il team di progetto partecipa a una sessione di pianificazione. Questa sessione prende due decisioni chiave:
Obiettivo dello sprint: si riferisce a ciò che può essere consegnato durante lo sprint.
Backlog dello sprint: l'elenco delle attività da completare durante lo sprint per raggiungere l'obiettivo.
La pianificazione dello sprint è un esercizio limitato nel tempo e di solito si svolge per un'ora alla settimana per un periodo di circa otto settimane.
La pianificazione degli sprint si adatta a Scrum e ad altri metodi Agile
La pianificazione degli sprint svolge un ruolo importante nell'universo delle metodologie di sviluppo Agile, che assegnano priorità alla capacità di risposta, alla flessibilità e al miglioramento continuo e cercano di aiutare le organizzazioni ad eccellere nella gestione del lavoro in un mondo in cui le priorità e i mercati stanno cambiando rapidamente. Con l'evolversi delle esigenze dei clienti e della concorrenza, la pianificazione degli sprint determina il lavoro da affrontare successivamente.
Nel software, la pianificazione degli sprint determina quali modifiche o funzionalità del prodotto possono essere fornite e come implementarle in modo più efficiente nell'iterazione successiva. Questo processo di pianificazione garantisce che il team affronti una quantità di lavoro realistica e completi prima il lavoro più importante. Dopo tutto, c'è un limite a quanto può essere realizzato durante uno sprint senza compromettere la qualità.
La pianificazione degli sprint viene utilizzata anche per i metodi Agile ibridi, come Scrumban, una crasi di Scrum e Kanban, il sistema di lavoro su base visiva e orientato al pull associato a Toyota. Scrumban combina iterazioni di lunghezza fissa con un processo standardizzato di hand-off; ciò significa che più di un team specializzato può lavorare su un singolo elemento di lavoro.
Per capire come funziona la pianificazione degli sprint con Scrum, è utile rivedere innanzitutto i processi e i ruoli chiave del metodo. Durante la pianificazione degli sprint, il team di progetto lavorerà con il product owner (lo stakeholder principale dell'azienda o dell'organizzazione del prodotto) ed è agevolato da uno Scrum Master (l'individuo che funge da servant-leader assicurandosi che il processo fluisca, formando il team e aiutando tutti a comunicare e comprendere la missione).
Questi partecipanti creano un backlog dello sprint, che è un elenco di funzioni o modifiche tratte dal backlog di prodotto che verrà sviluppato e implementato alla fine dello sprint. Il backlog dello sprint è formato dall'obiettivo dello sprint, cioè quello che può essere consegnato durante lo sprint.
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
"Un'abitudine molto semplice, ma molto utile: illustra sempre gli acronimi quando scrivi gli obiettivi dello sprint, le roadmap e la definizione di fatto. Non dare per scontato che tutti li conoscano, soprattutto quando ci sono nuovi arrivati nel team. Risparmiati molte spiegazioni e rielaborazioni. Scrivere gli acronimi ti costringe anche a rivalutare la novità dei concetti utilizzati a lungo. Tu (e il tuo team) ricordate davvero cosa dovrebbe accadere dall'inizio alla fine nel flusso E2E?" chiede.
Desideri un approccio più agile alla gestione dei progetti?
Scopri tutto quello che c'è da sapere sulla gestione dei progetti Agile e i suggerimenti per iniziare a implementare le best practice Agile per il PM.
Ottieni l'e-book gratuito per implementare le mie best practice Agile
Quanto dura una riunione di pianificazione degli sprint?
Gli esperti di Scrum consigliano generalmente di dedicare circa un'ora alla pianificazione per ogni settimana dello sprint, per un totale massimo di otto ore. I progetti altamente complessi possono richiedere più tempo. Inoltre, potrebbe essere necessario quasi il doppio del tempo a seconda della maturità del team Scrum.
Per capire perché la quantità di tempo in cui un team è stato insieme è un fattore così significativo nel determinare la durata di uno sprint, esamineremo il lavoro dello psicologo Bruce Tuckman, che nel 1965 ha proposto l'idea che lo sviluppo del gruppo procede attraverso fasi prestabilite:
Forming: quando un nuovo team si riunisce o nuovi membri vengono inseriti in un team
Storming: quando iniziano a scontrarsi su come lavorare
Norming: quando i membri del team fanno i conti con i ruoli e le relazioni di tutti nel gruppo
Performing: quando un team inizia a funzionare, massimizzando la produttività e riducendo al minimo gli attriti tra i membri
Non c'è da stupirsi, quindi, che i team ancora nelle prime fasi di sviluppo abbiano bisogno di un tempo di pianificazione più lungo per costruire il consenso rispetto ai team che lavorano insieme da più tempo.
Questo fattore di adattamento può spiegare perché la pianificazione degli sprint è vista da alcuni critici come una perdita di tempo. Al contrario, gli esperti di Scrum affermano che la pianificazione degli sprint è un precursore fondamentale per qualsiasi sprint. Per prima cosa, la pianificazione migliora l'efficienza di uno sprint e impedisce agli sviluppatori di fare il passo più lungo della gamba. Il processo crea anche il consenso con il proprietario del progetto sui deliverable dello sprint. Inoltre, dà agli sviluppatori Agile un senso di autorità sul loro lavoro e impedisce loro di sentirsi come se fossero costantemente nel tentativo di riconciliare le esigenze concorrenti con la propria capacità di lavoro.
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
La definizione dell'obiettivo dello sprint è fondamentale per il successo
Gli esperti affermano che lo sforzo investito nella definizione dell'obiettivo dello sprint paga i dividendi aiutando il team a garantire che lo sprint fornisca il massimo valore all'organizzazione e ai suoi clienti.
Il team scrive l'obiettivo dello sprint in collaborazione con il product owner e la dichiarazione dell'obiettivo è breve (solo poche frasi).
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
Come gli obiettivi in generale, i buoni obiettivi di sprint sono SMART (Specific, Measurable, Achievable, Realistic, and Time-bound (specifici, misurabili, raggiungibili, realistici e legati al tempo)). Ad esempio, un buon obiettivo di sprint per un team di sviluppo di una piattaforma freelance online potrebbe riportare qualcosa come "Creare un generatore di report sugli utili che fornisca la verifica dei redditi da freelance guadagnati in un anno fiscale" o "Creare un'interfaccia di messaggistica multimediale all'interno della piattaforma invece di fare in modo che i freelance e i clienti si affidino a servizi di messaggistica di terze parti." Gli obiettivi chiaramente indicati rendono facile comunicare le finalità e i progressi a coloro che non sono direttamente coinvolti nello sprint.
Nella stesura di un obiettivo sprint rientra una serie di considerazioni. Ad esempio, in che modo gli obiettivi di livello inferiore, progettati per essere raggiunti all'interno di un singolo sprint, si adattano con obiettivi strategici di alto livello o con la visione a lungo termine di un prodotto? Quali delle attività nel backlog di prodotto sono rilevanti per l'obiettivo dello sprint e devono essere incluse nel backlog dello sprint? E gli obiettivi dello sprint sono raggiungibili e realistici in base al numero di risorse e sviluppatori disponibile? Ricorda di tenere conto delle festività, delle ferie dei membri del team e degli eventi aziendali quando consideri il tempo disponibile.
L'obiettivo dello sprint non è una semplice formalità da completare e poi accantonare una volta che lo sprint è effettivamente in corso. Oltre a definire la direzione per tutto il lavoro da completare, è anche lo standard in base al quale si misura il successo di uno sprint nel corso della revisione post-sprint. Quindi conviene avere un obiettivo che il team, date le sue risorse, può effettivamente raggiungere.
La definizione del backlog dello sprint consente di impostare il piano di lavoro del team
Il backlog dello sprint comprende un elenco di attività da completare durante uno sprint. Sebbene sia redatto dal team Scrum in collaborazione con il product owner, quest'ultimo di solito non è impegnato nel processo di pianificazione degli sprint granulari. I team Scrum per definizione si organizzano autonomamente, quindi i membri del team guidano il processo. Spesso, il product owner non è in grado di sapere in che modo il team dovrebbe padroneggiare i compiti. In effetti, il diretto coinvolgimento dell'owner in questa parte della pianificazione può anche essere controproducente.
Invece, il ruolo del product owner è solitamente quello di specificare l'obiettivo dello sprint, preparare gli elementi candidati per il backlog dello sprint, dichiarare i requisiti per questi elementi e negoziare con il team di sviluppo la composizione del backlog fino a quando entrambe le parti non raggiungono un'intesa.
Naturalmente, il product owner si riserva il diritto di porre domande sugli elementi del backlog dello sprint, sul loro ordine e su come dovrebbero essere realizzati. Il team Scrum preparerà un elenco di elementi di backlog che si impegna a consegnare e un elenco di attività e attività secondarie necessarie per completare questi elementi. Nel corso del processo, il team stima anche l'impegno necessario per completare ciascun elemento del backlog, di solito utilizzando termini sintetici, come le taglie delle magliette o i punti della storia.
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
La mole di lavoro per un singolo sprint deve rimanere gestibile, di solito con un certo tempo di buffer integrato. Non è insolito assegnare il 20% della capacità di sprint come "tempo libero". Per fare questo, i team utilizzano una metrica chiamata velocità sprint, che corrisponde alla quantità di lavoro, nei punti della storia, completata durante un singolo sprint. In genere si utilizzano i dati dello sprint più recente; questa pratica si chiama "meteo di ieri", poiché si ritiene che la velocità dello sprint precedente sia la previsione più accurata dello sprint successivo. La velocità dello sprint viene regolata in base alla disponibilità dei membri del team e alla costituzione del team Scrum.
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
La pianificazione degli sprint può essere suddivisa in due fasi separate: la riunione WHAT e la riunione HOW. Durante la riunione WHAT, viene definito l'obiettivo dello sprint, viene creato il backlog dello sprint e viene decisa la capacità del team. Durante la riunione HOW, il team Scrum crea l'elenco delle attività necessarie per completare ogni elemento di backlog. Nel software, queste attività in genere riguardano la progettazione, l'implementazione, i test e la documentazione, e il completamento di ognuna non dovrebbe richiedere più di un paio di giorni. Se un'attività richiede più di un paio di giorni, gli elementi del backlog dello sprint sono troppo grandi per il lavoro di sprint; potrebbe essere necessario suddividerli.
Quindi, il team Scrum stima la quantità di lavoro da svolgere nelle ore necessarie per completare gli elementi di backlog e calcola la probabile durata totale delle attività dello sprint. In base alla capacità del team Scrum, se i membri ritengono di poter affrontare una quantità maggiore (o minore) di lavoro durante uno sprint, possono richiedere una modifica dell'iterazione per aumentarne o ridurne l'ambito.
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
Chi è presente alle riunioni sugli sprint?
Una sessione di pianificazione degli sprint prevede il contributo di tre stakeholder principali: il team Scrum, lo Scrum Master e il product owner.
Il team Scrum è composto dagli sviluppatori che si occupano dei dettagli del progetto. Durante la riunione di pianificazione dello sprint, è compito del team stimare e argomentare ciò che può e deve essere affrontato durante un singolo sprint. Il team Scrum si impegnerà quindi a raggiungere gli obiettivi dello sprint, a lavorare sul progetto e a garantire la consegna di una nuova iterazione che soddisfi i requisiti stabiliti durante la pianificazione dello sprint.
Lo Scrum Master è un facilitatore, un collegamento e un coach per il team Scrum. Solitamente sono sviluppatori più anziani e più esperti che comprendono come il lavoro del team si basa su obiettivi strategici generali, obiettivi a lungo termine e relazioni con i clienti. Lo Scrum Master gestisce le relazioni esterne del team (inclusa la relazione con il product owner) e si assicura che il team segua i principi dello sviluppo Agile. Durante la sessione di pianificazione degli sprint, lo Scrum Master guida il team Scrum a definire obiettivi adeguati per ogni sprint, fungendo da negoziatore tra gli sviluppatori e il product owner.
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
Il product owner è il principale stakeholder del progetto, la persona o la parte per cui il progetto viene realizzato. La misura in cui il product owner viene coinvolto nella pianificazione dello sprint varia, ma tende a non intervenire nella pianificazione delle attività di livello inferiore. Invece, si riserva l'autorità di dichiarare l'obiettivo dello sprint, di selezionare e dare priorità agli elementi del backlog dello sprint e di stabilire i requisiti di accettazione per ogni elemento.
Qual è l'obiettivo della riunione di revisione dello sprint?
La pianificazione dello sprint, ironicamente, inizia con la conclusione dello sprint precedente. Alla fine di ogni sprint, organizza una riunione di revisione, in cui il team Scrum esamina i risultati ottenuti e dimostra il funzionamento delle nuove caratteristiche e funzioni.
Di solito, alla revisione dello sprint partecipano il team Scrum, il product owner, lo Scrum Master, altri sviluppatori dell'organizzazione, la dirigenza e altre unità interessate. Mantieni l'atmosfera informale e la conversazione abbastanza fluida.
Durante questa sessione, valuta il lavoro del team rispetto all'obiettivo dello sprint stabilito durante la riunione di pianificazione. Il team ha completato ogni elemento del backlog dello sprint? Hai raggiunto l'obiettivo generale dello sprint? Ci sono state lezioni da applicare allo sprint successivo?
Preparazione di una riunione di pianificazione dello sprint
Prima di partecipare a una riunione sullo sprint, è bene controllare la roadmap del prodotto. Questo documento strategico delinea il modo in cui un prodotto si evolverà nel corso di una lunga serie di sprint e iterazioni. Gli elementi che alla fine compaiono nel backlog dello sprint devono essere allineati con la roadmap del prodotto, che quindi è bene tenere presente. Se gli elementi del backlog dello sprint non sono allineati con la roadmap del prodotto, quest'ultimo rischia di perdere la direzione.
Scarica il modello in formato Excel
Dovresti anche organizzare una riunione di pre-pianificazione con i rappresentanti del team Scrum, lo Scrum Master e il project owner. Questa riunione, che si tiene qualche giorno prima della riunione principale di pianificazione dello sprint, offre a tutti la possibilità di elaborare il backlog. Il backlog grooming è il processo di prioritizzazione, stima, dettaglio e determinazione dei criteri di accettazione degli elementi del backlog. Accelera la sessione di pianificazione e consente una maggiore produttività durante lo sprint, grazie a una corrispondenza più accurata tra la quantità di lavoro richiesta e la capacità disponibile.
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
"Consiglio di aggiungere un checkpoint a metà sprint o un'attività di grooming per riunire il team con il product owner e rivedere le storie aggiunte al backlog dello sprint successivo, porre domande e ottenere chiarimenti con largo anticipo rispetto alla riunione di pianificazione dello sprint successiva. [Fare] questo renderà la pianificazione dello sprint molto più efficiente e potrà addirittura dimezzare i tempi", spiega.
Scarica il modello di backlog di prodotto - Excel
Scarica il modello di backlog di sprint - Excel
Altri importanti stakeholder possono trarre vantaggio dalla partecipazione a una riunione di pre-pianificazione poiché offre a tutti la possibilità di assicurarsi di essere soddisfatti della prioritizzazione degli elementi del backlog. Questo è anche un buon momento per coinvolgere il progettista UX, in modo che possa iniziare a pensare a eventuali modifiche del design necessarie per gli elementi del backlog completati.
Quando si tratta di utilizzare le tecniche per determinare la priorità degli elementi del backlog, le correzioni di bug e le risoluzioni di problemi avranno in genere la posizione più alta nel backlog dello sprint. Un'altra pratica comune è quella di utilizzare la definizione delle priorità aziendali, in cui si chiede quali elementi del backlog siano più vantaggiosi per l'azienda e quindi si assegna loro la massima priorità. Ci sono alcuni possibili fattori da considerare, come il rischio coinvolto o mitigato dall'elemento del backlog e la quantità di valore aziendale che si prevede di generare. In mancanza di queste metriche, può essere utile anche il metodo di prioritizzazione MoSCoW, che assegna a ciascun elemento una priorità di tipo "deve avere", "dovrebbe avere", "potrebbe avere" o "vorrebbe avere". E, naturalmente, dovresti attingere all'esperienza dello Scrum Master nella definizione delle priorità dei backlog; dopo tutto, è lì come consulente del team.
Una riunione di pre-pianificazione di questo tipo aiuta anche il product owner ad assicurarsi che gli elementi del backlog soddisfino la definizione di "pronto" del team, cioè immediatamente attuabile. Poiché gli sprint non lasciano molto spazio alle perdite di tempo, i team di sviluppo avranno una serie di criteri per gli elementi del backlog che indicano se gli elementi sono pronti per essere lavorati.
In genere, si preparano prima gli elementi del backlog con i valori più grandi per la preparazione. Per un team tipico che lavora su attività tipiche, la definizione di "pronto" può includere uno o tutti i seguenti elementi: assegnazione dei valori dei punti storia, rimozione delle dipendenze, creazione di esempi testabili e definizione dei criteri di accettazione. Un semplice acronimo per spiegare una solida definizione di "pronto" è INVEST: independent (indipendente), negotiable (negoziabile), valuable (prezioso), estimable (stimabile), small (piccolo) e testable (verificabile). Le storie convalidate con INVEST sono pronte per passare al backlog dello sprint.
Allo stesso modo, il product owner può risparmiare tempo durante la riunione di pianificazione stabilendo i criteri di accettazione per gli elementi del backlog. Una descrizione semplice e oggettiva di ciò che l'implementazione di un elemento del backlog deve, dovrebbe e potrebbe raggiungere accelererà la discussione dei criteri di accettazione durante la riunione di pianificazione completa.
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
Le fasi di una riunione di pianificazione dello sprint
Ecco come si svolge una tipica riunione di pianificazione dello sprint:
Dipingi il quadro generale: Prima di iniziare la riunione, lo Scrum Master ricorda al team cosa sta cercando di ottenere e come si inserisce negli obiettivi strategici o nella roadmap di un prodotto. È utile anche che il product owner si prepari a parlare di due elementi di valore dello sprint per contestualizzare la direzione del prodotto a medio termine.
Aggiorna tutti: È il momento di scambiare tutte le informazioni che chi è coinvolto nell'imminente sprint dovrebbe conoscere. A questo punto possono essere condivisi le aggiunte recenti al backlog, i cambiamenti nella disponibilità dei membri del team o i nuovi input degli stakeholder.
Presenta la velocità target per il prossimo sprint: La velocità è il numero totale di storie degli utenti completate durante uno sprint. In genere, questa cifra deriva dall'ultimo sprint completato (il principio del meteo di ieri). Se da allora i membri del team Scrum, e non i numeri, sono cambiati, utilizza la velocità media degli ultimi tre sprint. Se questo è il primo sprint del tuo team, una buona cifra indicativa è di otto punti storia per sviluppatore per sprint; puoi sempre regolarla in seguito.
Conferma la capacità del team: La capacità del team viene calcolata come il numero totale di ore di lavoro dello sprint. Quindi, per un team Scrum di 10 persone che lavora 10 ore al giorno su un progetto di 10 giorni, la capacità sarebbe di 1.000 ore. Tuttavia, i team di solito detraggono il 20-40% dalla capacità massima per ottenere un numero più realistico che tenga conto dei tempi di inattività, delle spese generali e delle ore di lavoro perse. Inoltre, date le inevitabili dipendenze tra gli elementi del backlog, la capacità pratica può essere ulteriormente ridotta da una sorta di effetto domino, in cui le attività ritardate fanno slittare quelle successive. Se si prevede che alcuni fattori possano influenzare la velocità dello sprint o la capacità del team, registrali in questa fase.
Rivedi la definizione di "fatto": La definizione di "fatto" è un'istantanea di come sarà l'iterazione risultante alla fine dello sprint. È importante che chi esegue il lavoro e chi lo controlla concordino sulla definizione di "fatto" prima dell'inizio dello sprint.
Decidi quali elementi del backlog di prodotto andranno nel backlog dello sprint: In questa fase, il team Scrum deciderà anche se alcuni elementi del backlog sono troppo grandi per essere completati in un singolo sprint e devono essere rimandati.
Determina il fabbisogno di risorse, delinea chi farà cosa e stima il lavoro posseduto: Se c'è troppo lavoro che il team Scrum può ragionevolmente gestire, questo diventerà evidente per lo Scrum Master a questo punto. Assegna il lavoro e assicurati che gli incarichi dei singoli corrispondano alle loro capacità.
Definisci i criteri di accettazione: I criteri di accettazione sono standard misurabili per stabilire se un elemento del backlog è stato completato con successo. Specificare questi criteri è una prerogativa del proprietario del progetto, anche se il team Scrum può avere un certo margine di manovra per negoziare tramite lo Scrum Master.
Conferma e registra eventuali ipotesi, nuovi problemi o dipendenze identificate durante la pianificazione: Queste informazioni devono essere integrate nel backlog di prodotto.
Richiedi il consenso: È una prerogativa dello Scrum Master. Più o meno nello stesso momento, il team Scrum e il product owner indicheranno se ritengono che questo sia il miglior piano possibile per lo sprint.
Elabora i compiti coinvolti: Se il team Scrum ha bisogno di ulteriori informazioni, in particolare per quanto riguarda le specificità degli elementi del backlog dello sprint, a questo punto poni tutte le altre domande necessarie, in modo da poter trasformare le storie degli utenti in attività dettagliate.
Come organizzare e gestire una riunione di pianificazione dello sprint
Potresti organizzare la tua prima riunione di pianificazione dello sprint o cercare di rendere le tue riunioni più produttive. Sapere cosa è necessario coprire è importante, ma dovrai anche assicurarti di avere la logistica ben definita e le scorte a portata di mano.
Per uno sprint della durata di un mese, dovrai prevedere circa quattro ore di tempo: un'ora di riunione per ogni settimana di sprint. L'ideale sarebbe incontrarsi di persona, ma se hai membri del team a distanza, assicurati che la tua tecnologia di conferenza funzioni bene.
Per coloro che si riuniscono di persona, è necessario uno spazio di lavoro abbastanza grande da ospitare tutti. Organizza un sistema visivo come post-it, una lavagna o uno strumento elettronico. (Procurati dei post-it di colore diverso per rappresentare gli elementi di backlog). E poiché il team rimarrà lì per un po', avrete bisogno di snack e caffè per evitare che le persone diventino nervose.
Scarica l'agenda della riunione di pianificazione Sprint
Prima di iniziare la riunione, pubblica l'obiettivo e la velocità dello sprint nella sala riunioni, in modo che tutti possano farvi riferimento.
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
Usa i tuoi post-it per documentare gli elementi di backlog: ogni tipo di elemento viene contrassegnato con un post-it di colore diverso. Avrai bisogno di almeno tre colori: uno per le storie degli utenti, uno per le attività e uno per i bug. I post-it vengono poi appesi alla parete o alla lavagna in ordine di priorità. Dovrai ricreare questo backlog visivo per tutti i membri del team remoto.
Quando sei pronto per iniziare la riunione, apri celebrando i risultati ottenuti dal team durante l'ultimo sprint per iniziare le cose con il piede giusto. Successivamente, lo Scrum Master o il product owner presenterà le storie candidate per il backlog dello sprint, comprese quelle rimaste dall'ultimo sprint. Se non è stato fatto in fase di pre-pianificazione, le storie dovranno essere dimensionate, e ci sono alcuni modi per farlo. Alcuni team utilizzano le dimensioni delle magliette (XS, S, M, M+, L, XL, XXL, XXXL), mentre altri assegnano i punti storia utilizzando la sequenza di Fibonacci (1, 2, 3, 5, 8, 13, 21).
Indipendentemente dal sistema di dimensionamento utilizzato, i valori relativi sono più importanti dei valori grezzi. Inizia con due storie, decidi qual è la più grande e poi disponile in ordine. Quindi prendi una terza storia e decidi quanto è grande rispetto alle altre due, aggiungila alla classifica e così via. La somma dei punti storia deve essere inferiore alla velocità del team. Anche gli elementi del backlog di prodotto che passano al backlog dello sprint devono essere convalidati come pronti per essere lavorati.
Per il team Scrum, l'analisi di ogni storia dell'utente può richiedere molto tempo e ci sono diversi passaggi da considerare. Per esempio, questa storia è aggiornata o la sua definizione è cambiata? Ci sono nuove informazioni da considerare? Le stime per la storia sono ancora valide?
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
Una volta fissata la definizione della storia, questa deve essere suddivisa in attività. (Alcune di queste attività diventeranno storie degli utenti a pieno titolo.) Il team deciderà quali competenze specialistiche sono eventualmente necessarie per gestire queste attività e chiederà anche come testare la storia.
Proprio come i punti della storia e la velocità, la lunghezza stimata delle attività deve essere inferiore alla capacità del team per lo sprint. Alle attività e alle storie degli utenti che vengono spostate nel backlog dello sprint vengono assegnate date di scadenza, tenendo conto del numero di giorni lavorativi e delle ferie dei membri del team o del fatto che lavorino nel team Scrum part time.
Ricorda che non sono solo le storie degli utenti e le attività che le costituiscono a trovare spazio nel backlog ma anche le correzioni dei bug, che quindi occupano parte della capacità del team Scrum. Ma come si fa a decidere quanto spazio spetta a ciascun elemento del backlog? Un modo è quello di assegnare una percentuale fissa di capacità, ad esempio il 20%, alla correzione dei bug. Un altro consiste nel collegare le correzioni dei bug alle storie degli utenti e quindi dimensionarle e assegnare loro una priorità come se fossero storie degli utenti.
Infine, il team Scrum, lo Scrum Master e il product owner creeranno una definizione di "fatto", che includa una sorta di metrica di test per garantire la qualità della nuova iterazione.
Idealmente, la sessione di pianificazione dello sprint si concluderà con il raggiungimento di alcuni risultati. Questi includono: fare in modo che il team Scrum si senta a proprio agio con l'obiettivo e, a sua volta, che l'obiettivo si allinei con la visione strategica e la roadmap del prodotto; documentare adeguatamente il piano di sprint; creare un grafico di burndown (un grafico che traccia il lavoro rimasto da fare rispetto al tempo rimanente) per mostrare l'avanzamento del lavoro pianificato; e fare in modo che ogni sviluppatore del team Scrum sappia esattamente su cosa lavorerà una volta iniziato lo sprint.
Con il backlog dello sprint in ordine e l'obiettivo dello sprint in mente, lo sprint è pronto per iniziare.
Pianificazione degli sprint per il marketing Agile
Sebbene gli sviluppatori di software siano i professionisti Agile per eccellenza, non sono gli unici. Anche molti team di marketing stanno abbracciando con entusiasmo Agile.
Naturalmente, gli addetti al marketing non hanno iterazioni fisse di software da rilasciare. Ciò che hanno sono progetti in corso (spesso a lungo termine) che comprendono una serie di attività. Devono destreggiarsi costantemente tra le priorità a breve e medio termine, spesso con un obiettivo chiaro in mente per ogni nuova serie di sforzi.
Quindi, per gli addetti al marketing, l'adozione di metodi Agile è un modo per essere in grado di reagire in modo coordinato alle mutevoli condizioni di mercato, al contempo massimizzando l'efficienza e muovendosi verso un obiettivo chiaramente dichiarato.
Per la maggior parte, gli sprint e la pianificazione degli sprint per lo sviluppo di software e il marketing sono molto simili. Tuttavia, ci sono alcune differenze significative.
Per prima cosa, la durata degli sprint di marketing tende a essere più breve di quella degli sprint di sviluppo del software. Il tipico sprint di marketing non dura più di due settimane, mentre nello sviluppo del software non sono rari gli sprint di uno o due mesi.
In secondo luogo, le modifiche al backlog dello sprint durante il corso dello sprint sono più comuni nel marketing che nello sviluppo del software. Questa differenza è dovuta ai vincoli più rigidi imposti dalle attività tecniche dello sviluppo del software, mentre il marketing si presta a essere più fluido.
In terzo luogo, è probabile che in un team Scrum di marketing ci siano specializzazioni più ampie rispetto a un team Scrum di sviluppo software, poiché il primo comprende più discipline.
Best practice per la pianificazione dello sprint
Gli esperti raccomandano alcune best practice per ottenere il massimo dalla riunione di pianificazione degli sprint.
Quando invii l'invito alla riunione, includi l'ordine del giorno. Inoltre, prendi in considerazione la possibilità di aggiungere un link alle storie degli utenti candidate dal backlog di prodotto, in modo che gli sviluppatori abbiano un po' di tempo per esaminarle prima della riunione di sprint.
Quando il product owner prepara un elenco di storie degli utenti candidate dal backlog del prodotto, dovrebbe selezionare storie per un totale che superi la capacità del team Scrum. Questo perché è probabile che lo Scrum Master e il team Scrum rifiutino alcune storie degli utenti o le rimandino a uno sprint successivo. Se il product owner ha scelto un numero di storie inferiore all'intera capacità del team, le storie rifiutate si tradurranno in uno spreco di capacità durante lo sprint.
Ricorda che durante la riunione di pianificazione dello sprint è lo Scrum Master, non il product owner, a prendere il comando. Come il team Scrum, il product owner è più che altro un collaboratore della riunione: i product owner rispondono alle domande degli sviluppatori, spiegano le storie degli utenti e negoziano i criteri di accettazione con la mediazione dello Scrum Master.
È inoltre utile ricordare a tutti come possono contribuire nel modo più efficace e cosa possono o non possono aspettarsi dagli altri partecipanti. Il product owner, ad esempio, prende l'iniziativa di creare l'obiettivo dello sprint ed è responsabile della definizione dell'ambito dello sprint, della descrizione dettagliata di ogni storia dell'utente, completa di una definizione di "fatto", e della definizione delle priorità del backlog del prodotto.
Lo Scrum Master organizza la logistica dell'incontro e negozia le metriche chiave, come la velocità dello sprint e la capacità pratica del team. Inoltre, assume la guida nella finalizzazione del backlog dello sprint e modera le trattative tra il product owner e il team Scrum.
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
Il team Scrum raccoglie tutte le informazioni di cui ha bisogno per il prossimo sprint e si impegna a creare un backlog di sprint che sa di poter ragionevolmente consegnare. È inoltre compito del team informare lo Scrum Master se non sarà disponibile in qualsiasi momento dello sprint.
Una fonte comune di disfunzioni nella pianificazione degli sprint, afferma l'Agile coach Kevin Brunner, è la persona responsabile del backlog. Se non si è preparato per la riunione o non si fida che il team prenda decisioni da solo, la mentalità del team diventa quella di evitare invece dell'impegno. Gli sviluppatori, in particolare, possono lamentarsi del fatto che la riunione è una perdita di tempo poiché le storie degli utenti non sono state completate o perché la loro presenza non è necessaria perché il loro Scrum Master o il product owner prende comunque tutte le decisioni in modo unilaterale.
Per favorire una sana dinamica di squadra, Brunner sostiene che lo Scrum Master può seguire tre principi:
Visualizzazione: arrivare rapidamente alla fine di uno sprint con un'iterazione completata con successo e lavorare a ritroso da lì per negoziare i criteri di accettazione e ricavare le informazioni necessarie per consegnare l'iterazione completata. La visualizzazione fornisce al team un prodotto finale concreto intorno al quale si concentreranno gli sforzi.
Coltivazione: l'abitudine di prendere decisioni di squadra con il consenso e di ascoltare e rispettare l'input dei membri del team. La coltivazione consente inoltre al team di avere il tempo necessario per prendere decisioni e garantisce l'accettazione di aspetti chiave dello sprint, come l'ambito e le stime di tempo.
Riflessione: l'abitudine di guardare indietro a uno sprint una volta terminato per chiedersi cosa è andato bene, cosa no e come si potrebbe migliorare.
Una sana dinamica di team, afferma il coach Agile Tony Solomita, è definita da tre abitudini: preparare il backlog prima della riunione di pianificazione, ascoltare ciò che tutti hanno da dire durante il processo di stima e di finalizzazione del backlog dello sprint, e rispettare l'autorità del product owner sul motivo per cui una particolare funzionalità è necessaria e l'autorità degli sviluppatori sul modo in cui tale funzionalità sarà consegnata.
Domande frequenti sulla pianificazione degli sprint
Ecco le domande più frequenti sulla pianificazione degli sprint:
Come si gestiscono al meglio le dipendenze tra le attività? Esistono diversi modi per mitigare i potenziali effetti di perdita di tempo delle dipendenze dalle attività. In primo luogo, la pianificazione delle attività durante la riunione di pianificazione dello sprint può ridurre o eliminare attivamente le dipendenze complesse quando si suddividono le storie degli utenti in attività. In secondo luogo, è possibile creare un tempo di buffer tra le attività dipendenti, ove possibile. In terzo luogo, l'uso di progetti e tecniche di sviluppo flessibili e adattabili, come gli oggetti mock, può aiutare gli sviluppatori a gestire gli effetti delle dipendenze. In quarto luogo, avere gli sviluppatori che lavorano in prossimità l'uno dell'altro può prevenire i problemi di dipendenza, facilitando la comunicazione.
Per quanto tempo ogni membro del team dovrebbe iscriversi? Utilizzando il principio del meteo di ieri, ogni membro del team dovrebbe iscriversi per affrontare non più del numero totale di punti della storia nell'ultimo sprint.
Come si pianificano le iterazioni se le dimensioni del team variano? Sebbene i cambiamenti ricorrenti nelle dimensioni dei team non siano ideali, a volte sono inevitabili. Se le dimensioni del team cambiano, calcola il numero medio di punti della storia affrontati per sviluppatore nell'ultimo sprint e moltiplicalo per il numero di sviluppatori che parteciperanno al prossimo sprint per ottenere una cifra approssimativa per la velocità dello sprint. Potrebbe essere necessario modificare ulteriormente questa cifra in base alle persone che lasciano o entrano a far parte del team.
Come vengono contabilizzate le spese generali, come il tempo trascorso in riunione o a scrivere e-mail? Non esiste una regola generale per calcolare le spese generali, poiché variano da team a team. La maggior parte dei team si limita a presumere che in ogni sprint si spende una quantità di tempo costante per le spese generali e che la velocità degli sprint precedenti rifletta accuratamente il tempo dedicato alle spese generali.
Come si deve tenere conto della correzione dei bug? Ci sono due modi per affrontare la questione. Uno è quello di trattare i bug come storie degli utenti, stimando la quantità di lavoro necessaria proprio come per gli altri elementi del backlog dello sprint. Un altro approccio, più rischioso, è quello di non assegnare punti della storia ai bug, riducendo così la velocità del team. Il rischio di questo approccio è che funziona solo se si esegue la stessa quantità di lavoro per la correzione dei bug in ogni iterazione. Se la quantità di lavoro per la correzione dei bug varia, la velocità cambierà drasticamente da sprint a sprint, rendendo molto più difficile la pianificazione degli sprint futuri.
Perché le iterazioni devono essere sempre della stessa lunghezza? La risposta, in poche parole, è ritmo e coerenza. La sequenza di uno sprint procede molto più agevolmente se segue un ciclo regolare e facilmente prevedibile, il che semplifica notevolmente la pianificazione degli sprint.
Come si tiene conto del tempo dedicato ai test e alla documentazione? Il modo più semplice per farlo è includere il tempo dedicato ai test e alla documentazione come attività separata per ogni storia dell'utente. Un'alternativa è quella di creare un elemento separato nel backlog dello sprint per i test e la documentazione.
Le stime delle funzionalità devono essere riviste durante la pianificazione dell'iterazione? Solo se la stima originale è molto imprecisa.
Le stime delle attività devono essere riviste durante un'iterazione? No. Una volta completata la pianificazione dell'iterazione, lascia le stime delle attività come sono. Naturalmente, lo Scrum Master prenderà nota del motivo per cui il team ha scelto di modificare un'attività, in modo da poter riflettere queste informazioni nella futura pianificazione dello sprint.
Tutti i team dovrebbero operare con lo stesso programma di iterazione? Questo dipende dal numero di team Scrum che lavorano in tandem e dalla disponibilità del personale di supporto. Se non ci fossero vincoli a far lavorare più team su iterazioni iniziate e finite nello stesso momento, la sincronizzazione risultante sarebbe di grande vantaggio per la gestione. Ridurrebbe il rischio che il lavoro di un team imponga modifiche al backlog dello sprint di un altro, poiché i team si coordinano tra loro per la pianificazione dello sprint. In pratica, tuttavia, i team Scrum non lavorano in modo isolato e c'è un numero limitato di persone che ricoprono ruoli di supporto in più team Scrum e apprezzano iterazioni con date di inizio e fine scaglionate.
Errori comuni nella pianificazione dello sprint e segnali di allarme
Lo Scrum Master esperto conosce i segnali di allarme che indicano che la pianificazione dello sprint non sta andando bene come dovrebbe. Ecco a cosa fare attenzione.
Se un team non riesce ripetutamente a completare il suo backlog di sprint, se spinge continuamente le storie degli utenti allo sprint successivo, è segno che il gruppo sta sovrastimando la propria velocità e sta accettando troppe attività. Per garantire che la pianificazione sia accurata (ed effettivamente utile), lo Scrum Master dovrà regolare la velocità del team Scrum verso il basso.
Se, tuttavia, le stesse funzionalità vengono ripetutamente rinviate allo sprint successivo, è probabile che il team stia deliberatamente evitando di affrontare determinate storie degli utenti o correzioni di bug. Questa situazione merita di essere esplorata per capire se ci sono problemi relative a queste storie degli utenti o bug che non vengono sollevati durante la pianificazione degli sprint.
Il mancato completamento del backlog dello sprint potrebbe anche indicare un eccesso di progettazione, ovvero un caso in cui gli sviluppatori vanno oltre il loro lavoro, facendo di fatto più del necessario. Questo richiederebbe una revisione dei requisiti delle funzionalità richieste per assicurarsi che il team non stia spendendo sforzi inutili.
Cosa non fare: errori tipici nella pianificazione degli sprint
Una sessione di pianificazione degli sprint può essere sabotata da alcune insidie comuni:
Il product owner crea il backlog dello sprint da solo, senza il contributo degli sviluppatori: questo impegna il team Scrum in un backlog per la cui creazione non ha avuto voce in capitolo. Ciò riduce sia il loro impegno nel processo di pianificazione sia la probabilità che lo sprint raggiunga l'obiettivo prefissato.
Lo Scrum Master mostra per la prima volta le storie degli utenti candidate agli sviluppatori durante la riunione di pianificazione dello Sprint: un'inutile perdita di tempo che rende le riunioni di pianificazione molto più lunghe del dovuto. Se hai curato il backlog, è abbastanza semplice includere le storie degli utenti candidate nell'ordine del giorno della riunione. La presenza di storie degli utenti che non soddisfano i criteri di INVEST porterà a problemi simili.
Il team non si accontenta di una definizione di "fatto": quando ciò accade, il team consegna un prodotto incompleto alla fine dell'iterazione. Un segnale che indica che questo problema potrebbe essere incombente è la mancata suddivisione di tutti gli elementi del backlog dello sprint in una serie di attività gestibili.
Le attività secondarie non sono state accuratamente stimate: puoi individuare questo problema quando le attività non sembrano essere accuratamente stimate l'una rispetto all'altra. (Un'attività molto complessa non è un multiplo abbastanza grande di un'attività semplice.)
Lo Scrum Master impiega troppo tempo per raccogliere lo sprint backlog in uno strumento elettronico: ciò può significare che il team Scrum lavora alla cieca per i primi giorni dello sprint, senza riuscire a vedere i suoi reali progressi.
Le storie degli utenti candidate non vengono discusse con altri stakeholder prima di essere aggiunte al backlog dello sprint: anche in questo caso, questo tipo di errore invita gli stakeholder insoddisfatti a richiedere la modifica del backlog dopo che lo sprint è stato avviato. Anche alcuni product owner possono farlo, anche dopo aver firmato il backlog dello sprint originale, e può essere molto frustrante. Per alcuni team Scrum, un certo grado di modifica del backlog può essere praticamente inevitabile. In questo caso, ci sono una serie di possibili rimedi. Uno di questi è aumentare la lunghezza dello sprint o sottostimare intenzionalmente la capacità dello sprint, in modo da avere più margine di manovra se è necessario aggiungere del lavoro. Per i team il cui lavoro viene interrotto di frequente, la soluzione migliore potrebbe essere quella di limitarsi ad accettare la situazione e ridurre il tempo dedicato alla pianificazione degli sprint, poiché l'attività non può servire veramente allo scopo previsto.
Il team Scrum non dettaglia adeguatamente attività e attività secondarie: questo di solito è un segno che il team è annoiato dalla pianificazione e vuole solo andare avanti. Dettagli inadeguati rischiano di eliminare le stime quando gli sviluppatori scoprono che le attività richiedono più tempo del previsto.
I membri del team sono riluttanti a discutere i passaggi: in questo modo si toglie al resto della squadra l'opportunità di imparare.
Il team non dispone di uno Scrum Master che si occupi della pianificazione: senza uno Scrum Master che controlli il ritmo della sessione di pianificazione, tutti cercheranno di portarla a termine il prima possibile, il che può comportare una sessione di pianificazione frustrante e inefficace o saltare dettagli chiave.
Migliora la pianificazione degli sprint con Smartsheet for Project Management
Dalla semplice gestione delle attività e pianificazione dei progetti, alla complessa gestione delle risorse e del portfolio, Smartsheet ti aiuta a migliorare la collaborazione e ad aumentare la velocità del lavoro, consentendoti di ottenere di più. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.