{"id":152,"date":"2021-01-29T06:39:41","date_gmt":"2021-01-29T05:39:41","guid":{"rendered":"https:\/\/www.alecerme.it\/raggi\/?p=152"},"modified":"2025-09-28T09:45:31","modified_gmt":"2025-09-28T09:45:31","slug":"14-strategie-per-dividere-gli-elementi-del-backlog","status":"publish","type":"post","link":"https:\/\/alecerme.it\/raggi\/14-strategie-per-dividere-gli-elementi-del-backlog\/","title":{"rendered":"14 strategie per dividere gli elementi del backlog"},"content":{"rendered":"\n

Nella vita di tutti giorni, come “Scrum master”, mi trovo a lavorare con tre team diversi, ognuno con caratteristiche, composizione, difficolt\u00e0 e complessit\u00e0 da affrontare diverse, composti in totale da una ventina di persone. <\/p>\n\n\n\n

Il nostro lavorare in team prevede una filosofia “Agile” orma da un p\u00f2 di anni e “Scrum” \u00e8 il framework che, al momento, troviamo pi\u00f9 conforme alle nostre esigenze. <\/p>\n\n\n\n

Una delle difficolt\u00e0 trasversale a tutti i team<\/strong> che seguo e che ho visto durante il mio percorso, \u00e8 il lavoro sul Product Backlog<\/strong> (PBI) e nello specifico scomporre gli elementi del PBI in storie pi\u00f9 piccole<\/strong>.<\/p>\n\n\n\n

A volte \u00e8 molto difficile far capire alle persone<\/strong> e a volte, agli sviluppatori stessi, che lo sviluppo del software \u00e8 intrinsecamente imprevedibile<\/strong> .<\/p>\n\n\n\n

Quindi, se il lavoro per uno sprint contiene solo pochi elementi di grandi dimensioni, l’impatto di sottovalutare il lavoro<\/strong> anche su un singolo elemento<\/strong> avr\u00e0 un impatto profondo<\/strong> sullo sprint. E poich\u00e9 gli elementi pi\u00f9 grandi tendono ad essere pi\u00f9 difficili da stimare e comprendere<\/strong>, il potenziale per uno sprint fallito aumenta ulteriormente<\/strong>.<\/p>\n\n\n\n

\n

Sprint Backlog con molti elementi piccoli (funzionali) invece di pochi grandi, migliorano il flusso e riducono il rischio di fallire lo sprint<\/strong>, diminuiscono gli imprevisti e generano nel breve tempo valore per il cliente.<\/strong><\/p>\nChristiaan Verwijs<\/cite><\/blockquote>\n\n\n\n

Gli Scrum Team esperti <\/strong>impiegano tempo e sforzi per scomporre grandi PBI in storie pi\u00f9 piccole<\/strong>. Ma questo viene fatto in un modo “just-in-time”<\/strong>. Questo processo <\/strong>di scomposizione del lavoro migliora<\/strong> la comprensione condivisa<\/strong>, aumenta l’accuratezza della stima<\/strong> e facilita<\/strong> il Product Owner nella definizione delle priorit\u00e0<\/strong> del lavoro. <\/p>\n\n\n\n

Ma<\/strong> non \u00e8 facile farlo bene e richiede pratica per farlo “al volo”<\/strong>.<\/p>\n\n\n\n

\"\"
Photo by Bonneval Sebastien on Unsplash<\/em><\/figcaption><\/figure>\n\n\n\n

Fatta questa premessa per capire l’importanza di questo processo, ho trovato illuminante<\/strong> e utile l’articolo di The Liberetors<\/a> che descrive 14 tecniche da mettere in atto per scomporre “al volo”<\/strong> grandi PBI in storie pi\u00f9 piccole<\/strong><\/strong>.<\/p>\n\n\n\n

Le tecniche che descrivono sono:<\/p>\n\n\n\n