Grooming e socialismo reale

groominggrooming / ˈgruːmɪŋ/n. strigliatura f., preparazione f., governatura f.;

In agile si chiama grooming la gestione quotidiana del product backlog, che comporta l’ordinamento delle user stories in ordine di priorità, la divisione delle user stories troppo grosse, la cura delle descrizioni e dei contenuti di ciascuna user story, fino ad arrivare a un backlog che sia più vicino possibile al modello stratigrafico di deposito fluviale (geologi si nasce, qualunque altra cosa si diventa!): elementi grossolani e irregolari in basso, elementi fini e ben lavorati in alto.

Il grooming è una attività che spetta principalmente al Product Owner e in parte al team, con e senza il suo PO: per estensione siamo spesso soliti chiamare grooming gli incontri in cui PO e team lavorano insieme alla preparazione del backlog. In questo senso il grooming è una preziosa occasione di condivisione dei punti di vista, un punto di incontro tra le richieste del cosa (di cui il PO si fa portavoce) e quelle del come.

Non ho trovato mai indicazioni univoche su come organizzare un grooming, credo che nessun Cohn o Schwaber se la sia mai sentita di dare prescrizioni su qualcosa che può avere un’immensa variabilità in dipendenza di tantissimi elementi (team, product owner, tipo di progetto, stadio di maturità del progetto…). Voglio scrivere due cose su come noi siamo stiamo organizzando i nostri incontri di grooming in questo momento: in atmosfera assolutamente agile non è escluso che possa cambiare del tutto idea tra un mese.

Io e il mio team facciamo 2 incontri di grooming generale ogni sprint (che per noi sono di due settimane).

Il primo incontro è l’occasione per volare un po’ più in quota del solito e dare un’occhiata al progetto dall’alto, facciamo previsioni su dove saremo al prossimo sprint e a quello successivo e li contestualizziamo nel planning generale del progetto.

Condividiamo le nostre priorità almeno per i prossimi 6-8 sprint, quindi 4 mesi, e con questo orizzonte diamo un senso alle attività previste per i prossimi due sprint. Si fa una sorta di brainstorming moderato, ci si allinea sugli obiettivi.

E’ un incontro molto bello che i membri del team vivono come una nuova ed emozionante esperienza di partecipazione.

Il secondo grooming generale è invece molto più di dettaglio: si discute davanti a un lista di tasks, o meglio user stories, già abbastanza ben definite e ordinate, si finisce di discutere eventuali punti oscuri e si fa una prima stima di story point per facilitare il lavoro del Product Owner di organizzazione delle priorità e definizione del set definitivo di storie da portare al planning.

Poiché il primo incontro porta ad una analisi molto di massima e il secondo è per contro uno studio molto di dettaglio è chiaro che in mezzo ci deve essere un grosso lavoro di definizione delle user stories e di scomposizione delle attività troppo grandi. Al momento la soluzione più fruttuosa e meno dispendiosa per tutti è stata quella di organizzare dei grooming separati con singole persone o piccoli gruppi (es. con tester, con designers, con sviluppatori di backend, di frontend etc.) e concentrare in questi mini incontri la maggior parte del faticoso lavoro di mediazione tra i diversi punti di vista del “come fare” e del “cosa fare”.

Diciamo che è una soluzione aperta: nei primi 10 sprint della mia vita ho già cambiato pensiero almeno 5 o 6 volte e non posso escludere che anche il processo che ho illustrato possa avere delle modifiche in futuro; diciamo solo che per ora funziona abbastanza.

Lascia una risposta