Mi chiedo se durante lo sviluppo di un backlog di prodotti, le attività abbiano ore stimate per loro. Per confermare, posso parlare di un product backlog qui non di uno sprint backlog come so che ha.
Il tipo preferito di Product Backlog Item per un team Scrum è una User Story non un'attività.
Le storie degli utenti sono generalmente valutate in Story Points . Non esiste un punto preciso in cui stimare una storia.
I team di Scrum usano Pianificazione del poker per stimare storie, che la maggior parte dei team di solito fa poco dopo che il backlog iniziale è stato creato . Quando nuove storie vengono generate attraverso lo sviluppo, i team tendono a eseguire Planning Poker per stimare quelle storie una volta per iterazione. Alcuni team non stimano affatto e contano solo il numero di storie, anche se questo si basa su rompere storie fino a una fine granularità.
Il tempo in cui i team Scrum normalmente creano attività è durante Sprint Planning Meeting . Il team crea l'elenco delle attività necessarie per fornire tutti gli elementi del backlog del prodotto selezionato. Di solito, anche ogni attività sullo sprint backlog viene stimata.
Come per le storie degli utenti, ho visto diverse tecniche utilizzate per stimare il lavoro richiesto. Alcune squadre usano i punti storia, altri usano "giorni uomo ideali". Alcune squadre di nuovo non si preoccupano e usano il numero di compiti. Lo scopo di stimare questi compiti è che tu possa tenere traccia dei progressi all'interno di uno sprint e come controllo secondario (ai punti della trama) che il team non sta facendo troppo lavoro.
Non ho mai realmente compiti sul backlog del prodotto, normalmente li terrei in uno sprint. Tuttavia, ho aggiunto in precedenza Spi al backlog del prodotto. Tuttavia, non sono realmente stimati - sono time-box, il che significa che stabilisci un limite di tempo in cui lavori all'interno. Uno Spike è un tipo di esercizio di raccolta di informazioni, il codice che viene creato è destinato ad essere gettato via. Dopo il picco, di solito usi le informazioni raccolte per creare storie che possono essere valutate nel modo usuale.
In realtà non uso ore per stimare il backlog del prodotto, perché spesso è in una lingua che non si presta facilmente alle stime dell'ora (e idealmente, è quello che dovrebbe essere lo sprint backlog, poiché capisco il processo ).
Usiamo il sistema di punti (o arrotondato Fibonacci se preferisci) e scaliamo le attività per complessità. Ad esempio "Ok, l'utente A vuole la rappresentazione grafica di questi elementi", e attraverso l'esperienza, sai che può essere difficile ma non troppo dispendioso in termini di tempo. Se 1 è facile e 21 è complesso, potrebbe essere un 4. L'utente B vuole un grafico interattivo che può essere modificato al volo aggiungendo / sottraendo punti dati / unità aziendali. Questo ottiene un 15.
Inoltre, non hai assolutamente bisogno di dettagliare i punti per tutto il tuo arretrato. Alcuni oggetti potrebbero non essere mai raggiunti. Fai abbastanza per il futuro prevedibile e lavora dall'alto verso il basso così com'è (o dovrebbe essere) già in ordine di priorità.
Devi anche considerare il ROI, in quanto un'attività di 3 può essere più veloce di una 5 attività, ma l'attività 6 produrrà X% di entrate in più. È abbastanza da farlo urtare? Devi decidere.
Di solito è troppo dispendioso in termini di tempo stimare le ore per gli articoli nel backlog. Il tuo team può dedicare tempo alla stima dell'ora, mentre questo articolo arretrato potrebbe non arrivare mai in cima. Di conseguenza, di solito solo gli articoli che lo trasformano in uno sprint sono stimati in ore mentre vengono suddivisi in pezzi più piccoli per le attività sprint.
Leggi altre domande sui tag agile scrum sprint product-backlog