Passaggi da fare per creare il Product Backlog per l'avvio del nostro progetto con Scrum

Il modulo ideale per gli elementi del tuo backlog è User Story .

Sono facilmente mantenibili. Non dimenticare che il backlog è uno strumento per organizzarli (stime + prioritizzazione), non per documentarli.

Ti suggerisco di dare un'occhiata a User Story in tutto il ciclo di vita Agile

La prima cosa da ricordare su Agile è che è più una filosofia che una metodologia. Fai ciò che funziona per te. Puoi iniziare con qualcosa di formalizzato come Scrum o qualsiasi altra cosa, ma a un certo punto devi personalizzarlo.

Quello che facciamo è tentare di valutare tutte le storie che abbiamo. Se c'è qualcosa di troppo complesso o grande per un singolo sprint (che per noi è di 2 settimane), allora lo dividiamo. Cerchiamo di dividerlo in pezzi che contano. Ad esempio, disegnare il testo su una visualizzazione diagramma. La storia 1 è di avere il testo lassù. La storia 2 deve essere in grado di selezionarla e spostarla. La storia 3 è di averla mossa quando si sposta ciò a cui è collegato. La storia 3 deve consentire all'utente di cambiare il carattere ... ecc ... ecc. Abbiamo qualcosa di abbastanza utile alla fine di ogni sprint che, se così fosse deciso dai dirigenti aziendali, potrebbe effettivamente rilasciare il prodotto in questo modo.

Questo bit richiede un bel po 'di tempo e non dovresti dare per scontato che lo si possa ottenere perfetto o addirittura provare a farlo necessariamente. Vuoi solo qualcosa che sia ragionevolmente d'accordo per mostrare progresso e velocità man mano che la tua squadra progredisce.

Hai un progetto che è stato sviluppato per 5-6 anni e ora vuoi creare un nuovo progetto che richiederà solo 1 anno. C'è un'evidente discrepanza che porta a una sola domanda: hai un Product owner che capisce il sistema attuale, capisce i bisogni di un nuovo sistema ed è abilitato dal management a definire le priorità per le funzionalità implementate nel corso del prossimo anno? Se la risposta è no, hai un grosso problema e finché non lo risolvi non devi continuare. Hai bisogno di questa persona che avrà responsabilità e potere di definire il progetto in base alle reali esigenze di business / utente / cliente.

Hai 25 funzionalità, ma qual è la dimensione delle tue funzionalità? La descrizione più comune della funzione è la User story. La storia dell'utente non è una documentazione della funzionalità: è "promessa" di una discussione / comunicazione futura che definisce il contenuto e i vincoli della discussione. Le storie degli utenti dovrebbero essere piccole: nessuna storia utente può estendersi più di una singola iterazione (sprint). Se hai funzionalità più grandi puoi chiamarle Epiche e Temi. Il tema è area intera / dominio aziendale e può essere diviso in più Epic. Epic è un ampio set di funzionalità che definiscono alcune funzionalità principali e possono essere suddivise in più user story.

User story, Epic and Themes definisce il backlog del prodotto ma solo le User story devono essere pianificate per un'iterazione. Una volta che qualcosa viene definito come Epico o Tema significa che è troppo grande e incerta per una squadra fare una stima valida e deve essere divisa prima che possa essere pianificata. È compito del proprietario del prodotto definire le storie degli utenti e dividere epopee e temi.

È molto comune (e valido) che non tutte le funzionalità siano conosciute all'inizio e non tutte possono essere definite all'inizio del progetto (se provi a farlo, tornerai a cascata). Il backlog del prodotto in agile viene definito e modificato continuamente durante l'intero sviluppo del progetto. Se hai bisogno di una specifica / portata del tuo progetto, proviamo a definire temi e possibilmente le epiche più importanti. Questo ambito non sarà riparato. Mentre crei un'applicazione, alcuni temi / epiche / storie utente sono obsolete o il tuo programma non ti consente di includerlo in una versione. Allo stesso tempo è possibile aggiungere un altro tema più importante / epico o una semplice user story.