Il perfezionamento del product backlog (PBR) è il processo continuo di miglioramento dell'elenco del lavoro (software) da svolgere. Il PBR è la pietra angolare per decidere cosa deve essere fatto e in quale ordine. In questo articolo descriviamo le principali attività di perfezionamento del product backlog e come possono essere accelerate con l'analizzatore di requisiti intelligente di ScopeMaster®.
Perfezionamento del portafoglio prodotti
Il perfezionamento del Product Backlog è l'attività regolare svolta dalla maggior parte o da tutto il team in una riunione con l'obiettivo di preparare le attività per le prossime iterazioni. Le attività chiave sono:
- Chiarire le storie degli utenti, in modo che il team ne abbia una comprensione comune.
- Dividere le storie che sono troppo grandi per adattarsi a un'iterazione.
- Creazione di nuove storie utente e rimuovendone altri in base alle nuove conoscenze.
- Assegnazione preventivos alle storie
- Assegnazione delle priorità alle storie
Il perfezionamento del product backlog è un'attività molto dispendiosa in termini di tempo e denaro, che in genere assorbe il 5-15% dell'intero tempo di lavoro dei team. Eppure è assolutamente essenziale in quanto è il passo fondamentale per garantire che il team lavori sulle cose giuste. Se non si dedica tempo sufficiente a questo, il team perderà tempo in attività sbagliate, il che può essere ancora più costoso.
Esaminiamo ciascuna di queste attività PBR un po' più in dettaglio e vediamo come l'automazione può essere d'aiuto.
Cosa va nel Product Backlog?
Un product backlog contiene generalmente storie di utenti (che descrivono funzionalità), epiche ad alta granularità e storie di utenti più dettagliate. Il product backlog dovrebbe escludere altre attività che potrebbero essere coinvolte ma che non forniscono direttamente funzionalità all'utente.
Attività di affinamento del backlog:
1. Chiarire le storie degli utenti
La lingua inglese è estremamente flessibile. Abbiamo molte parole alternative per la stessa cosa. Possiamo cambiare l'ordine delle parole per alterarne il significato e cambiare il modo in cui verrà interpretata la storia. Le variazioni sono quasi infinite, anche una user story di 12 parole ha 87 miliardi di permutazioni nell'ordine delle parole. Con ogni variazione è probabile che l'interpretazione del lettore sia leggermente diversa. E anche in questo caso, l'interpretazione di una user story da parte di ciascun individuo dipende dal proprio vocabolario e dalle proprie capacità linguistiche. È più che probabile che due persone qualsiasi che leggono una user story abbiano interpretazioni diverse.
Se i membri del team non condividono una comprensione comune di un elemento del backlog, è probabile che coloro che successivamente lavoreranno su di esso perderanno tempo a costruire/testare la cosa sbagliata. Una comprensione coerente da parte dell’intero team è quindi essenziale per ridurre al minimo gli sforzi sprecati.
Secondo scrum.org "In genere un elemento del Product Backlog passa attraverso tre riunioni di perfezionamento prima di essere considerato pronto." Per rendere questa discussione fruttuosa, migliore sarà la qualità della storia che entrerà nella riunione, meno tempo verrà sprecato.
La maggior parte degli elementi del backlog descrivono l'intento funzionale, il Chi E Che cosa della storia dell'utente. È qui che ScopeMaster può eliminare completamente le ambiguità in una frazione del tempo, eliminando lunghe discussioni.
2. Suddividere le storie per adattarle allo sprint
Le storie utente agili dovrebbero essere completate entro una singola iterazione o sprint (in genere due settimane). Il completamento di una singola storia non dovrebbe estendersi su due sprint. Il completamento dovrebbe includere anche tutti i test unitari. Se una storia è troppo grande, deve essere suddivisa in brevi parti. Tipicamente uno sviluppatore sarà in grado di costruire (compresi i test unitari) circa 8 Punti Funzione COSMIC (CFP) per sprint. Questa stima della produttività individuale varia in modo significativo, ma se una singola storia supera gli 8 CFP, dovrebbe essere condivisa tra più di un membro del team e/o suddivisa in “morsi” più piccoli, ciascuno dei quali può essere completato all’interno di uno sprint/iterazione.
La capacità di ScopeMaster di rilevare le dimensioni funzionali fornisce un preventivo immediato se una storia necessita di essere divisa.
3. Creazione di nuove storie utente e rimozione di altre
I team software devono adattarsi alle mutevoli esigenze del business. Durante il perfezionamento del backlog sarà necessario dividere alcune storie, crearne di nuove e rimuoverne altre. Ciò garantisce che il lavoro svolto sia mirato alle esigenze aziendali così come sono attualmente conosciute. Creare nuove storie per soddisfare le mutevoli esigenze va bene, ma il cambiamento dovrebbe essere limitato ove possibile, poiché livelli eccessivi di cambiamento interrompono il team. Molte “incognite” sono infatti “conoscibili”. I cambiamenti dovrebbero essere limitati a quelle cose che inizialmente erano inconoscibili. Ove possibile, è utile anticipare i requisiti generali il prima possibile. Ciò aiuta a pianificare il lavoro del team nel modo più efficiente.
La capacità di ScopeMaster di analizzare una serie di storie utente alla ricerca di funzionalità mancanti e duplicate consente al team di comprendere meglio l'ambito generale molto prima.
4. Assegnazione di stime alle storie
La stima delle storie è forse uno degli aspetti che richiedono più tempo nel perfezionamento del product backlog. In genere ciò comporta il gioco di “story poker” in cui i partecipanti alla squadra indovinano lo sforzo richiesto per fornire la storia in formato maglietta o successivamente in punti della storia (arbitrari). Non solo richiede molto tempo, ma è noioso, soggettivo, incoerente e di scarsa utilità per la gestione del progetto, soprattutto su un progetto su larga scala. Inoltre, le stime dei punti della storia vengono solitamente “giocate” per ottenere un risultato particolare.
La capacità di ScopeMaster di stimare immediatamente la dimensione funzionale delle storie degli utenti (in punti funzione COSMIC) significa che il team deve dedicare pochissimo tempo alle riunioni discutendo la dimensione della storia. La dimensione funzionale del racconto raffinato è un valore coerente, standardizzato e immutabile. Ciò libera tempo per il team per discutere i modi migliori per farlo Come per trasmettere la storia nel modo più efficiente.
5. Assegnare priorità alle storie
Dare priorità alle storie è una conseguenza di quanto sono importanti per l'azienda, da quali altre storie dipendono e quanto impegno saranno necessari per fornire. Se le altre attività di perfezionamento del backlog sono già state parzialmente o per lo più automatizzate, il team può dedicare più tempo a discuterne nelle riunioni di perfezionamento del backlog. Ciò contribuirà a garantire che la squadra faccia ciò più importante le cose nel giusto ordine.
