Stima tutte le storie utente in iterazione zero?

Non ho mai visto nessuno stimare l'intero arretrato del prodotto. In genere, ciò che accade è che il product backlog ha la priorità su base continua dal Product Owner. Scrum ha un'attività in corso nota come perfezionamento del backlog in cui il proprietario del prodotto e il team di sviluppo esaminano gli articoli del backlog del prodotto e aggiungono dettagli sufficienti per implementare gli articoli, le stime e il riordino secondo necessità (forse a causa di una maggiore comprensione della complessità o delle dipendenze tecniche) . Con Sprint Planning, un buon numero di articoli del Product Backlog viene perfezionato e il team ottiene un numero sufficiente nello Sprint, in base alla sua priorità nel Product Backlog.

I criteri di accettazione devono essere aggiunti dal Product Owner prima della stima. Poiché i criteri di accettazione sono basati sulle esigenze di business (sia le esigenze funzionali che eventuali attributi di qualità non associati associati all'elemento Product Backlog), il Product Owner è nella posizione appropriata per associare tali esigenze a ciascun articolo del Product Backlog. Se vi è un lavoro aggiuntivo che il team ritiene necessario per completare correttamente l'articolo, è possibile aggiungerlo durante la discussione del preventivo per garantire che tutto il lavoro necessario sia documentato e incluso nella stima. Il team può quindi includere il lavoro necessario non solo per completare, ma anche per verificare e convalidare il completamento dell'articolo nel preventivo.

Inoltre, non ho mai visto un "grafico di burndown del prodotto". Il grafico di burndown è in genere per uno sprint individuale, non per l'intero progetto. Il giorno 1 dello sprint, il grafico di burndown riflette il valore riportato nello sprint. Quando si implementano elementi dallo Sprint Backlog, il grafico viene aggiornato per riflettere il valore rimanente da implementare nello sprint. Non vedo perché non è possibile avere un grafico di burndown del prodotto basato sull'elemento Product Backlog perfezionato, ma poiché gli elementi del Product Backlog vengono aggiunti, perfezionati e rimossi, il grafico oscillerà - ciò dovrebbe accadere molto più regolarmente rispetto alla modifica dell'ambito come definito in Sprint Backlog.

In base ai tuoi commenti nella risposta di Thomas Owens, vorrei aggiungere alcuni punti. Sono d'accordo con la sua risposta!

Nel primo (pochi) Sprint (i) non è possibile fare una buona stima per il tempo del progetto. Forse conosci il Cono di incertezza ? Dice:

At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty.

Soprattutto in Scrum, dove hai obiettivi / compiti / requisiti molto grandi e vaghi che verranno specificati in dettaglio mentre il progetto è in esecuzione.

Probabilmente conosci anche le 4 parole chiave: prezzo, qualità, tempo e caratteristiche. I progetti standard cercheranno di fissare Prezzo, Tempo e Caratteristiche. È più probabile che la qualità soffra in questo modo. Scrum tenta di fissare la qualità, passando la variabile alle caratteristiche. Dato che potenzialmente potresti essere in grado di spedire un prodotto dopo ogni sprint, le funzionalità potrebbero essere abbandonate o posticipate a favore di altre, più importanti (dal punto di vista del cliente).

Ora per la stima del tempo del progetto. Puoi stimare quanto affermato da Thomas Owens, forse un po 'più di quanto ti aspetti di finire in uno sprint. Ora puoi "indovinare" il resto del lavoro semplicemente prendendo una quantità media di Storypoints per le storie. La quantità totale di Storypoints è molto inaffidabile, ma hai la tua prima "ipotesi".

Quando inizia il tuo prossimo sprint, hai stimato un'altra serie di storie. Meno compiti (o forse più) sono ora nel backlog del prodotto. Forse hai già un'idea migliore di ciò che una storia media richiede. È possibile aggiornare la stima ora. La quantità totale di punti di memoria per il tuo prodotto cambia. E dopo il terzo sprint, forse, hai una buona idea di quanto ci vorrà davvero. Almeno vedrai, se è possibile completare tutte le funzionalità con la configurazione corrente (in base alla velocità).

Modifica: ho dimenticato di menzionare: forse è meglio rendere la tabella di rilascio del prodotto un tabella .

Non è necessario stimare l'intero arretrato. È ordinato in modo da poter stimare le prime storie.

Se hai bisogno di fare un piano di rilascio e il suo grafico, dovrai stimare abbastanza storie per coprirlo. Quindi se vuoi pianificare 3 mesi in anticipo, dovrai stimare almeno 3 mesi di storie.

Per la gestione che è in grado di pianificare a livello di rilascio è molto importante.

La stima delle storie è generalmente più rapida della stima durante il piano di rilascio e può essere eseguita in qualsiasi momento.

Tutti questi suggerimenti sembrano fare un'ipotesi piuttosto ampia: le storie degli utenti possono essere prioritarie senza alcuna stima. Non ho mai lavorato in un ambiente dove è possibile - forse grandi aziende che hanno tonnellate di soldi da bruciare. Per me, sembra il modo più veloce per bruciare i soldi VC ... cercando di costruire le cose più importanti / impossibili prima senza costruire anche dei frutti a bassa attaccatura che possano aiutare a colare un po 'di soldi.

Utilizziamo il seguente metodo:

Valuta ciò che sai

Rifiuta di stimare ciò che non fai e chiamalo spike

Comunicare alla direzione che deve essere eseguito almeno 1 picco. Il risultato / deliverable di un picco è una stima per la storia (o storie) per cui è stato creato lo spike o una sorta di email, documento, powerpoint, ecc. Che indica le lezioni apprese e i prossimi passi suggeriti per il prossimo picco.

Dopo 2, 3 o più picchi per esigenze aziendali, diventa rapidamente evidente all'intera squadra e al management che si tratta di un'area rischiosa e piena di incertezze. E, dal momento che alla direzione non piacciono le cose che non hanno stime, tendono a dare la priorità ai picchi ... vogliono le loro stime. Ad ogni modo, funziona bene - tutte le storie ad alto rischio e incerte iniziano a ribollire fino all'inizio della pubblicazione e quindi tutti hanno un quadro molto più chiaro su cosa è realistico e cosa non lo è.

Ancora meglio, la leadership impara rapidamente che i picchi non sono impegni poiché non sono stimati e i nostri team non si impegnano a cose che non sono stimate.

Il passaggio finale: un percorso critico per i vari componenti dell'applicazione (UI, database, servizi, ecc.), che significa picchi e storie. So che questo può sembrare assurdo e non è necessario eseguire un percorso critico completo per l'ingegneria dei sistemi, ma solo un rapido "questo impedisce o impedisce che questo venga lavorato". Devi identificare rapidamente cosa può essere fatto in parallelo, cosa è bloccato, ecc. Ciò aiuta davvero a definire piani di rilascio, temi di sprint e punti cardine.

L'unica volta che vorresti stimare l'intero arretrato è se ti viene richiesto di produrre una stima per il completamento di TUTTE le funzionalità. Ciò si verifica quando si cerca di integrare SCRUM con progetti che richiedono una data di "fine" per l'intero progetto.

Supponendo che tu non abbia bisogno di una data "terminata" per l'intero backlog, allora valuterò semplicemente le cose per la prossima iterazione o due in dettaglio e proseguirò con lo sviluppo. Dato che hai una priorità per il backlog, non ti serve molto di più.

Dopo aver dato la priorità al Product Backlog cerco sempre di stimare tutte le User Story come parte della sessione Sprint Planning per Sprint 0. Ci sono stati solo un paio di progetti quando c'erano semplicemente troppe storie per fare in modo che fossero pratici in uno Sprint Planning session. Quando ciò accadeva, mentre stavamo valutando le storie secondo l'ordine della loro priorità, quando avevamo finito il tempo lasciavamo solo le storie a bassa priorità non stimate che non intendevamo lavorare nel primo Sprint. Siamo stati quindi in grado di completare la stima del resto delle storie nella sessione di pianificazione per il prossimo Sprint: non sprecare tempo prezioso nello sviluppo per la stima, limitarlo alle sessioni di Sprint Planning a tempo.

Usiamo la stima relativa in Story Points che arriviamo attraverso Planning Poker. Ciò rende l'intero processo abbastanza facile e veloce che è quasi sempre possibile stimare l'intero Product Backlog all'inizio del progetto.

In risposta alla tua seconda domanda; se ci sono specifici criteri di accettazione per una User Story, sì, questi dovrebbero essere aggiunti quando la storia viene creata. Se non lo fai, come hai identificato, sarà difficile stimare non menzionare difficile da attuare correttamente! Se si dispone di criteri generali di accettazione applicabili a tutte le storie (forse un tempo massimo di risposta per qualsiasi transazione o una quantità minima di copertura del codice), queste dovrebbero essere definite in una definizione di fatto. Questo forma un insieme di standard di qualità che ogni membro del team deve colpire prima di poter dichiarare una storia completa.

Personalmente preferisco non creare un Product Backlog generale in quanto i dati che rappresenta possono essere fuorvianti. Visto che le nuove User Story dovrebbero apparire sempre, mentre tu stai bruciando contro il backlog, spesso ne aggiungi di più. Mostrare il numero di User Story incomplete o il totale dei Story Story incompleti nel tempo non è necessariamente una buona rappresentazione dell'avanzamento del progetto.

E io tendo ad essere in disaccordo con il sentimento condiviso qui che non si dovrebbero stimare interi arretrati o come può essere fuorviante.

Secondo la mia esperienza, se stimare l'intero arretrato è un lavoro ingrato o fuorviante, l'arretrato è troppo grande o il team non è bravo a stimare o la squadra non lo sa, l'uscita è troppo ambiziosa, ecc. spara per 3 mesi di rilascio (6 sprint).

Abbiamo anche due definizioni di fatto ... quella con cui la maggior parte delle persone ha familiarità e la "definizione convalidata del fatto". La maggior parte di voi probabilmente ha familiarità con noi è piuttosto negligente. Abbiamo bisogno di qualcosa fatto abbastanza per metterlo là fuori, ottenere feedback e imparare da esso. In genere, questo è il proprietario del tuo prodotto che "accetta" la storia. Tuttavia, abbiamo appreso molto presto che i proprietari dei prodotti fanno dei proxy scadenti per gli utenti e quindi non "convalidiamo" una storia finché non viene sottoposta al test dei veri utenti finali. Una volta che ci sentiamo a nostro agio, non abbiamo ricevuto nessun feedback negativo o sono stati sottoposti a test di usabilità, lo contrassegneremo come "validato". Una volta convalidato, questo significa che dovremmo puntellarlo con alcuni test dell'interfaccia utente automatizzati, controlli di qualità, ecc. Vogliamo incidere questa storia utente in pietra - il nostro proprietario del prodotto ha detto che soddisfa i requisiti aziendali e che i nostri utenti non hanno problemi con sia.

Ho sentito parlare di altri casi in cui, anche se gli utenti non hanno un problema con esso, potrebbe non essere mai convalidato, quindi viene effettivamente inserito in un repository di "codice scartato". Se non aiuta l'app a vendere, gli utenti non lo usano mai, gli utenti non lo amano necessariamente ... perché spendere le risorse per metterlo in porto, mantenerlo, ecc.