Grooming dei task nello sviluppo mobile: cos'è, obiettivi e processo di conduzione

Cos'è il grooming dei task?

Backlog Grooming (affinamento) è il processo di preparazione degli elementi del Product Backlog per gli sprint futuri. È una riunione in cui il Product Owner e il team di sviluppo esaminano i task: chiariscono i requisiti, aggiungono Acceptance Criteria, stimano la complessità, identificano dipendenze e rischi. Non esiste un evento obbligatorio chiamato “grooming” nella Scrum Guide — è una pratica aggiuntiva che i team Scrum adottano per ridurre l’incertezza durante lo Sprint Planning. La frequenza raccomandata è una volta per sprint, con una durata massima di 60 minuti.

Il termine “grooming” riflette l’essenza: il team “pettina” il backlog, rimuovendo i task obsoleti, chiarendo quelli ambigui e suddividendo quelli troppo grandi. Nello sviluppo mobile, il grooming è particolarmente importante a causa delle specificità della piattaforma: un task Android può differire in complessità dalla versione iOS, e bisogna considerare targetSdk, compileSdk e la compatibilità con i livelli API. Senza grooming, lo Sprint Planning diventa caotico — il team vede i task per la prima volta e non riesce a stimarli, portando a imprevedibilità e ritardi.

Il risultato del grooming è un insieme di task pronti per lo Sprint Planning: hanno descrizione, Acceptance Criteria, stima e soddisfano la Definition of Ready. Il Product Owner dovrebbe affinare i task in ordine di priorità: quelli più vicini allo sprint corrente devono essere i più dettagliati. I task a 3–4 sprint di distanza devono rimanere a livello di epic. Tecnica di Progressive Refinement: più un task è vicino allo sprint, più la sua descrizione è dettagliata. Per i task dello sprint corrente — affinamento completo (AC, design, specifica API). Per i task a 2 sprint — livello story (user story senza dettagli implementativi). Per i task a 3+ sprint — livello epic (solo nome e valore business).

Definition of Ready: quando un task è pronto per lo sprint

Definition of Ready (DoR) è una checklist di criteri che un task deve soddisfare prima di essere incluso nello Sprint Backlog. Il DoR è un contratto tra il Product Owner e il team: il PO garantisce che tutte le informazioni necessarie per lo sviluppo siano disponibili, e il team garantisce di poter stimare e completare il task. Il DoR non è universale — ogni team definisce il proprio set di criteri. Senza DoR, un task può entrare in uno sprint con requisiti poco chiari, portando a rilavorazioni e ritardi.

DoR tipico per lo sviluppo mobile: 1) Gli Acceptance Criteria sono descritti (formato Given-When-Then). 2) Il mockup di design è pronto in Figma (per i task UI) con tutti gli stati: default, loading, error, empty state. 3) La specifica API è approvata (OpenAPI/Swagger, esempi di richieste e risposte). 4) La stima in story point è disponibile. 5) Le dipendenze da altri task sono identificate. 6) Il task non dipende da componenti esterni non completati. 7) Specificità mobile: versioni target del sistema operativo definite, necessità di feature flag, supporto per vecchi livelli API.

Tecniche di stima dei task

Planning Poker è la tecnica di stima più popolare durante il grooming. Ogni sviluppatore riceve un mazzo di carte con i numeri di Fibonacci (1, 2, 3, 5, 8, 13, 21). Il PO presenta un task e lo spiega. Dopo la discussione, tutti mostrano la propria carta simultaneamente. Se le stime divergono significativamente (ad esempio 3 e 13), gli sviluppatori spiegano le loro ragioni e votano di nuovo. Le iterazioni si ripetono fino al raggiungimento del consenso. Lo scopo del Planning Poker non è la stima precisa, ma scoprire le differenze nella comprensione del task.

T-Shirt Sizing è una tecnica semplificata per stime rapide: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). È adatta per la cernita iniziale del backlog quando ci sono molti task e serve un ordine di grandezza approssimativo. Dopo il T-Shirt Sizing, viene effettuata una stima più precisa tramite Planning Poker per i task del prossimo sprint. Affinity Estimation è una tecnica di raggruppamento in cui i task vengono disposti su un tavolo dal più semplice al più complesso senza usare numeri, poi raggruppati in cluster e ogni cluster riceve una stima.

Nello sviluppo mobile, la stima deve considerare la complessità della piattaforma. Un task Android può essere stimato 5 SP mentre lo stesso task per iOS può essere 3 SP (o viceversa). Questo è normale: piattaforme diverse hanno diversa complessità di implementazione. Suggerimento: stimate ogni piattaforma separatamente se il team è cross-platform. Usate una scala relativa: un task di base (ad esempio, una schermata con testo e pulsante) = 1 SP. Tutto il resto è relativo ad esso. Secondo Scrum.org (2025), dopo 3–4 sprint, la precisione di stima del team raggiunge ±20% della complessità reale.

Scomposizione: come suddividere i task grandi

I task più grandi di 8 SP devono essere scomposti in task più piccoli. I task grandi non possono essere completati in un singolo sprint, sono difficili da stimare e non danno un senso di progresso. Tecniche di scomposizione: dividere il task per layer orizzontali (UI → ViewModel → Repository → Network/DB) o per slice verticali (funzionalità: una schermata completa). La scomposizione orizzontale funziona meglio per lo sviluppo mobile: Sotto-task 1 — layout UI (XML/Jetpack Compose/SwiftUI), Sotto-task 2 — ViewModel + State, Sotto-task 3 — Repository + Network, Sotto-task 4 — Test unitari.

Scomposizione verticale — suddividere le user story in storie più piccole con valore indipendente. Esempio: Epic “Carrello della spesa” → Story 1 “Aggiungere articolo al carrello”, Story 2 “Mostrare il carrello”, Story 3 “Rimuovere articolo dal carrello”, Story 4 “Checkout”. Ogni storia ha il proprio valore business e può essere rilasciata indipendentemente. SPoK (Story Points on Kano): classificate le storie per valore business (Must-have, Should-have, Could-have) e implementatele in ordine di valore.

Checklist di scomposizione durante il grooming: 1) Il task è più grande di 8 SP? → Scomporre. 2) Gli Acceptance Criteria sono definiti? → Se no, aggiungerli. 3) Dipende da altri task? → Identificare e documentare le dipendenze. 4) Contiene incertezza? → Aggiungere uno Spike (ricerca) prima del task principale. 5) Serve design? → Verificare la disponibilità dei mockup. Regola INVEST: Independent (indipendente da altri), Negotiable (negoziabile), Valuable (di valore per il business), Estimable (stimabile), Small (piccolo), Testable (testabile). Se un task non soddisfa INVEST, non è pronto per lo sprint.

Processo di grooming: passo dopo passo

Passo 1: Riscaldamento (5 minuti). Lo Scrum Master ricorda al team l’obiettivo del grooming e il DoR. Il team guarda la bacheca e il PO mostra quali task saranno discussi. Passo 2: Revisione dei task (30 minuti). Il PO presenta sequenzialmente i task dalla fine dello sprint corrente all’inizio del successivo. Per ogni task: nome, descrizione, Acceptance Criteria (se presenti), link al design, specifica API. Il team fa domande di chiarimento: “C’è un mockup per lo stato vuoto?”, “Che metodo HTTP?”, “Qual è il minimum deployment target di iOS?”

Passo 3: Stima (15 minuti). Il team stima il task tramite Planning Poker o T-Shirt Sizing. Se la discrepanza è maggiore di 2 SP, discutono le ragioni e votano di nuovo. Regola: se un task non può essere stimato (requisiti poco chiari, nessun design), viene restituito al PO per perfezionamento e tornerà al prossimo grooming con chiarimenti. Non stimate task con incognite — questo garantisce errori nello sprint. Passo 4: Registrazione dei risultati (10 minuti). Il PO registra le stime in Jira/Linear, aggiorna la descrizione del task e imposta le priorità.

Risultati del grooming: 3–7 task completamente preparati per lo Sprint Planning (con DoR, stima, design, API). Il PO aggiorna il backlog: rimuove i task obsoleti, unisce i duplicati e perfeziona le priorità. Importante: il grooming non conclude il lavoro del PO — tra le sessioni di grooming, il PO deve preparare i task successivi. Ritmo raccomandato: il PO prepara 3–4 task per il grooming e il team li elabora. Se ci sono più di 50 task nel backlog, il PO deve effettuare una prioritizzazione (MoSCoW o Weighted Shortest Job First) prima del grooming.

Differenze tra grooming e Sprint Planning

Il grooming è preparazione. Non ci sono impegni — il task viene semplicemente chiarito e stimato. Sprint Planning è un impegno. Il team seleziona i task tra quelli preparati durante il grooming e si impegna a completarli entro lo sprint. Differenze chiave: il grooming non è legato a uno sprint specifico (affinamento del backlog nel suo complesso), non c’è Sprint Goal durante il grooming e il grooming può essere svolto in qualsiasi momento dello sprint. Lo Sprint Planning avviene rigorosamente all’inizio dello sprint e porta sempre a un Sprint Goal.

Durante il grooming, i task vengono solo stimati, ma non portati nello sprint. Durante il Planning, i task vengono selezionati dal pool preparato. Senza grooming, lo Sprint Planning dura 6–8 ore (invece di 4), perché il team vede i task per la prima volta e non riesce a stimarli rapidamente. Regola 80/20: l’80% dei task allo Sprint Planning dovrebbe essere completamente pronto (aver superato il grooming), il 20% può essere nuovo (bug urgenti, hotfix). Se al Planning più del 20% dei task non è stimato, il grooming è stato insufficiente.

Errori comuni del grooming

Errore 1: grooming una volta al mese. Il team accumula task di 3–4 sprint e cerca di affinare tutto in 2 ore. Risultato: metà dei task rimane non stimata e il Planning occupa l’intera giornata. Soluzione: il grooming deve essere regolare — una volta per sprint, 60 minuti. Se ci sono molti task, aggiungete un secondo grooming a metà sprint. È meglio affinare pochi task a fondo che molti superficialmente. Ritmo: 3–5 task per sessione di grooming, ciascuno con discussione e stima complete.

Errore 2: stima senza contesto. Il PO presenta un task “Implementare la schermata del carrello” senza design, API o AC. Il team stima “a occhio” — 13 SP. Durante il Planning si scopre che in realtà sono 5 SP (perché la schermata è semplice). Soluzione: un task non viene stimato se non ha design o API. Il PO deve preparare i materiali prima del grooming. Regola: “Niente mockup, niente stima”. Eccezione: task Spike — ricerca di incertezza, vengono stimati separatamente senza design (2–5 SP a seconda della complessità della ricerca).

Errore 3: il grooming si trasforma in Planning. Il team inizia ad assegnare i task alle persone e a discutere chi farà cosa. Soluzione: ricordare che il grooming serve a chiarire, non ad assegnare. L’assegnazione avviene durante il Daily dopo l’inizio dello sprint. Il grooming risponde “cosa fare?”, il Planning risponde “quando farlo?”, il Daily risponde “chi lo sta facendo?”. Mescolare queste domande in una riunione riduce l’efficacia di ciascuna. Lo Scrum Master deve interrompere le discussioni simili al Planning e reindirizzare l’attenzione sul chiarimento del task.

Errore 4: ignorare il debito tecnico. Durante il grooming si discutono solo nuove funzionalità; i task tecnici vengono ignorati. Dopo 3–4 sprint, il debito tecnico si accumula a un livello critico. Soluzione: a ogni grooming, almeno 1 task tecnico deve essere stimato. Proporzione: ogni 3 funzionalità → 1 task tecnico. Usate la metrica Tech Debt Ratio: rapporto tra task tecnici e task funzionali in uno sprint. Valore target: 0.25–0.3 (25–30% del tempo sul debito tecnico). Se il rapporto è inferiore a 0.2, la velocità di sviluppo diminuirà negli sprint successivi.