Time Tracking in Scrum [chiuso]

Question

Nota: prima di porre questa domanda ho fatto una ricerca esaustiva e ho trovato piccole parti della risposta in varie altre domande, ad esempio:

• Qual è la miglior risorsa per imparare Scrum?
• Scrum Process Gestione: suggerimenti, insidie, idee
• Due domande su Scrum

Tuttavia, ritengo che questa domanda non sia stata affrontata direttamente (se lo è, per favore fatemi sapere).

Tieni traccia del tempo in Scrum in funzione delle ore / dei giorni trascorsi in un'attività o semplicemente se tale attività è completa o no? Puoi adattare tali compiti e stime?

Background: Il nostro nuovo vicepresidente dello sviluppo proviene da un ambiente Scrum, e quindi stiamo tutti imparando a conoscere il processo, ma una delle cose che ha portato con sé è il concetto di citando le stime delle ore effettive che ogni attività dovrebbe richiedere di completare, con l'intenzione di essere più accurate con le nostre stime nel tempo: quindi una volta avviato un progetto non possiamo aggiungere nuove attività o regolare le stime orarie su tali attività.

Ma ho capito che le pratiche agili, in particolare Scrum, erano basate sul concetto di attività come bucket che memorizzavano singoli obiettivi realizzabili e che le si aggiungono / rimuovono / adeguano man mano che le esigenze dei clienti si evolvono dopo ogni sprint.

Mi rendo conto che questo potrebbe essere potenzialmente polemico, ma presumo che vedere Scrum come un processo, solo uno di questi concetti sia il "corretto". filosofia per quel sistema.

Answer 1

  

Tieni traccia del tempo in Scrum in funzione delle ore / dei giorni trascorsi in un'attività o semplicemente se tale attività è completa o no?

Traccia il lavoro rimanente stimato . Questa è un'informazione indispensabile. Senza questo, non puoi disegnare il grafico di Burndown. Senza il grafico di Burndown, non sai " dove " lo sei, non sai se il tuo Sprint è ancora in pista o no. Ciò renderebbe questo strumento decisionale piuttosto inutile. Sì, il grafico di burndown non è uno strumento di monitoraggio, è uno strumento decisionale.

  

Puoi adattare quelle attività e stime?

Certo!

In realtà, il team possiede le stime , nessun altro, ed è compito dello ScrumMaster garantire l'applicazione di questo principio. Questo dovrebbe già rispondere alla domanda. Ma ci sono altri motivi.

Come ho detto, uno Sprint Backlog e un grafico Burndown sono strumenti decisionali e dovrebbero quindi essere rappresentativi di dove sei realmente. Se nascondi la realtà, se non sei trasparente, questi strumenti non ti aiuteranno a prendere alcuna decisione preziosa, saranno inutili. Pensaci, che senso ha avere dei bei numeri se sono inutili? Qual è il punto di avere un "bello burndown" " se non riflette la realtà.

Quindi, durante uno Sprint, i membri del team dovrebbero ovviamente aggiornare le stime del lavoro rimanente non appena possono farlo (verso l'alto o verso il basso). Se inizialmente una stima dell'attività era 6 ore, ma il team scopre che è necessario svolgere più lavoro e che l'attività richiederà effettivamente 8 ore, il team dovrebbe aggiornare di conseguenza il backlog Sprint. Se qualcuno ha trascorso 4 ore su un'attività inizialmente stimata in 4 ore ma ha ancora bisogno di 2 ore di lavoro, queste 2 ore dovrebbero essere riportate nello Sprint Backlog. Se il team scopre un'attività che deve essere eseguita ma che non è stata identificata, la squadra deve aggiungere questa attività e la sua stima al backlog Sprint. E non essere precisi all'inizio non è un problema, purché si aggiorni l'arretrato con le conoscenze raccolte nel tempo. Prima fai questi aggiornamenti, prima sarai in grado di adattarti e prendere decisioni.

Detto questo, può essere utile mantenere la "stima iniziale" e confrontarlo con il "tempo effettivo impiegato per completare". Ma non a scopo di tracciamento, solo per aiutare il team a fare stime migliori. In realtà, consiglierei di non farlo se si sta passando a Scrum. Spesso ci sono molti altri impedimenti da risolvere, molte altre cose da migliorare prima di apprendere valori e principi Scrum. E se lo fai, fai attenzione ai demoni Waterfall. Preparati a combatterli, potrebbero tornare molto velocemente.

Answer 2

Le risposte che vedo qui non sono sbagliate, ma non credo che abbiano davvero risposto alla tua domanda.

Penso che tu stia chiedendo, " Dovrei tenere traccia delle ore totali effettivamente spese per un determinato compito? " La risposta è, " Puoi, se necessario, ma non fa parte di Scrum. & Quot;

Scrum è un processo molto leggero. Definisce / richiede solo ciò che è necessario per far funzionare Scrum. Puoi (e, in molti casi, probabilmente dovresti) sovrapporre altri processi su Scrum per soddisfare le tue esigenze organizzative. Ad esempio, se il monitoraggio delle ore totali effettivamente spese per un'attività consente di stimare meglio attività simili in futuro (come sembra che il tuo VP voglia), allora potrebbe essere un buon motivo per tenere traccia delle ore totali, a condizione che non lo faccia interferire troppo con il lavoro produttivo. O forse è necessario conoscere le ore totali ai fini della fatturazione. Quindi solo perché Scrum non richiede qualcosa non significa che non dovresti farlo.

Tuttavia, ai fini di Scrum stesso, non è necessario tenere traccia delle ore totali effettivamente spese per un'attività. Non è necessario per nessuno degli artefatti Scrum, che tracciano solo il tempo stimato rimanente.

Answer 3

Non so se la nostra implementazione è "corretta", ma quello che facciamo è:

• Sono stati aggiunti elementi di backlog , su cui è stato inserito un numero complessità stimato (in relazione ad altri elementi di backlog).
• Prima di ogni sprint, esaminiamo gli articoli arretrati in ordine di priorità (prioritario dal proprietario del prodotto), suddividendoli in attività per le quali facciamo una stima del tempo (in ore).
• Quando il numero di ore disponibili nello sprint è esaurito, lo sprint è pieno

Quindi, durante lo sprint, dopo ogni giorno di lavoro, regoliamo i tempi delle attività su cui stiamo lavorando, in modo che mostrino il numero di ore che pensiamo che sia rimasto prima che l'attività venga completata . Ciò significa che se ho un compito di 6 ore, ci lavoro per un giorno intero (consideriamo 6 ore un giorno intero) e poi sento che mi rimangono ancora 2 ore prima che sia fatto, quindi abbasso le "ore rimaste" ; da 6 a 2. Nel caso in cui l'attività sia programmata per tempo, dobbiamo invece verificare le ore effettive utilizzate, ovviamente.

Answer 4

Devo aggiungere qualcosa qui perché

  

ma una delle cose che ha portato con sé è il concetto di quotare con molta attenzione le stime delle ore effettive che ogni attività dovrebbe richiedere di completare, con l'intenzione di diventare più accurate con le nostre stime nel tempo: quindi una volta avviato un progetto non possiamo aggiungere nuove attività o modificare le stime orarie su tali attività.

È semplicemente una mischia non , quindi non so dove il tuo VP abbia ottenuto le sue informazioni. Le attività (note come voci di backlog dello Sprint) non vengono create fino alla pianificazione dello sprint successivo. Sono creati appena in tempo e certamente non prima dell'inizio del progetto. Prima dell'inizio del progetto (Sprint 0), il Product Owner crea il Product Backlog e lo riempie di storie. Può aggiungervi in ??QUALSIASI momento durante il progetto. È suo da gestire. Il team stima approssimativamente queste storie l'una contro l'altra nei punti della trama o in qualche altra misura relativa (giorni ideali?).

La stima delle attività in ore è solo uno strumento che il team utilizza per capire a quante storie impegnarsi nello sprint e quindi per tracciare i progressi per prevedere il successo (burndown). Una volta che una squadra si è gelata e ha una velocità storica; potrebbe decidere di non eseguire alcun tracciamento in poche ore e di tracciare il loro burndown nei punti della storia o nel numero di storie. Stimare in ore è una forma di spreco in sé se il team non ne ha bisogno per raggiungere l'impegno per gli obiettivi dello sprint.

Vorrei chiedere al vicepresidente cosa sono questi "molto attenti" le stime stanno per essere realizzate.

Answer 5

Stima il tempo, ma non importa se è perfetto

Assicurati solo di stare attento e stimare le attività accuratamente. Fondamentalmente non si misura davvero il tempo, perché è più soggetto a errori. Il modo migliore è utilizzare le stime temporali delle attività come punti della storia . In questo modo otterrai:

1. Se le stime del tempo sono disattivate, la ricerca mostra che tendono ad essere costantemente disattivate (il fattore di precisione non cambia troppo), quindi le stime del tempo possono essere facilmente utilizzate per il calcolo dei punti della storia.
2. Se sei riuscito empiricamente a fare x numero di punti della storia nello sprint precedente, probabilmente otterrai risultati simili questa volta anche se le tue stime del tempo non sono corrette.
3. Dovrai essere piuttosto bravo a stimare tutte le attività della storia. Altrimenti i punti della tua storia dello sprint tendono a crescere durante l'esecuzione e non rispetterai la scadenza, anche se la tua velocità rimarrà praticamente la stessa
4. Le stime possono cambiare ma in modo simile al n. 3, mantenere un po 'di tempo libero per queste modifiche per rispettare le scadenze dello sprint (giorno della demo).

Ma mantieni le stime del tempo per vedere quali attività devono essere divise o unite.

Answer 6

Tracciamo sia il tempo impiegato a lavorare sulle attività, sia il tempo rimanente per completarle. Il tempo rimanente consente di determinare i progressi realizzati durante lo Sprint e di prevedere se saremo in grado di raggiungere l'obiettivo dello Sprint. Aggiorniamo il tempo rimanente per le attività, adeguandolo (a volte aumentandolo) su base giornaliera.

Il tempo impiegato è - presumibilmente - per la micro gestione. Offre inoltre al team la possibilità di ottenere un feedback sull'accuratezza delle stime e di migliorare la stima e di mostrare in che modo le interruzioni impediscono al team di lavorare sul backlog di Sprint e quindi rallentarlo.

Nel processo Scrum, i singoli obiettivi realizzabili sono chiamati Backlog Items e possono essere visti come un secchio di attività. Agli articoli arretrati viene assegnata la priorità dal proprietario del prodotto, stimato dal team, prima nel suo insieme e poi attività per attività. Il contenuto, l'ambito, la priorità e la stima degli articoli arretrati possono essere modificati.

Stimiamo sia le voci di Backlog sia le attività in unità di tempo (giorni o settimane per le voci di Backlog, ore per le attività) e applichiamo un fattore di concentrazione (rapporto del tempo dedicato a lavorare esclusivamente sulle attività Sprint) per tenere conto per il tempo non impiegato a svolgere attività per raggiungere l'obiettivo Sprint.

Answer 7

Per quanto riguarda il monitoraggio del tempo, quello che stai cercando è un grafico di burndown .

Fredrik ha spiegato cos'è un burn down, senza usare il termine. In sostanza, riesaminare regolarmente il tempo rimanente per una determinata attività.

Quindi alla tua domanda se tracciamo o meno il tempo trascorso , non necessariamente. A Scrum piace invece lavorare con tempo rimanente . (Potresti sostituire le ore con i punti della storia, il principio è lo stesso, come ha spiegato Robert.)

Alla tua seconda domanda se puoi adattare i tuoi compiti e le tue stime, sicuramente sì. Agile segue la filosofia "reattivo al cambiamento"; dai la priorità a ciò che è più importante per il cliente.

Tuttavia, alcuni team preferiscono non aggiungere / eliminare / riordinare le attività in un particolare sprint una volta iniziato, dal momento che è quasi un modo di lavorare ad hoc, e anche la mischia richiede una certa struttura e disciplina.

La dichiarazione ", quindi una volta avviato un progetto non possiamo aggiungere nuove attività o regolare le stime orarie su tali attività." quasi certamente non è nello spirito di agile.

Answer 8

Utilizziamo la tecnica Pomodoro per tenere traccia del tempo rimanente. Uno dei suoi vantaggi è che la quantità di tempo trascorso viene registrata in modo disciplinato.

Dopo aver stimato le storie nei punti della storia, stimiamo le attività in termini di pomodori e utilizziamo questa stima (che può essere riesaminata ad hoc) per giudicare il tempo rimanente. Alla fine dello sprint è facile vedere quali attività abbiamo inizialmente stimato in modo meno accurato e migliorare il modo in cui stimiamo in futuro, grazie al modo in cui segniamo il numero di pomodori stimati e completati su ogni post-it.

In termini di sprint, le ore stimate rimanenti sono solo una misura dei progressi, quindi possiamo vedere dove siamo in termini di burndown. Sono un indizio sul fatto che siamo sulla buona strada o no. Il punteggio che conta sono i punti trama completati.

Answer 9

Per definizione, un elemento viene eseguito quando tutte le attività che devono essere completate per implementare completamente quell'elemento sono rimaste 0 ore. Quello che devi tenere traccia all'interno dello sprint sono le ore rimanenti sulle attività rimanenti. Non ore trascorse in un'attività. Perché? Perché la nostra conoscenza di quanto tempo impiegherà qualcosa è imperfetta e guadagniamo poco cercando di elaborare una stima super accurata quando dovremmo lavorare sul prodotto.

Puoi sempre aggiungere attività sotto un elemento di backlog di sprint mentre identifichi più lavoro che deve essere fatto per implementare completamente l'elemento e dovresti aggiornare le ore rimanenti al completamento ogni giorno (o impostarle su 0 una volta che hai completato l'attività).

Dovresti dire al tuo VP che sapere quando spedirai il prodotto in base alle tue informazioni più accurate (oggi) è molto meglio che impostare un numero / fare una stima in passato e non aggiornarlo mai. Ciò non significa rivalutare le storie utente (non farlo fino alla fine del rilascio), significa aggiornare il backlog dello sprint con nuove attività e la migliore stima su quando le attività attive saranno completate nelle ore rimanenti.

A proposito, il modo di lavorare su stime accurate è pianificare il tuo rilascio usando i punti della storia, creare un piano di iterazione basato sulla velocità stimata del tuo team e quindi aggiornare continuamente il piano di iterazione basato sull'output alla fine di ogni sprint . Dopo pochissimi sprint, avrai un'idea molto precisa della velocità effettiva della squadra, rendendo più semplice prevedere quando spedirai il rilascio con l'ambito desiderato ... o quale ambito dovrebbe essere completato entro la data di spedizione originale. L'uso dei dati di progetto effettivi del progetto corrente per prevedere il completamento del progetto è una buona pratica di ingegneria del software, poiché è il modo più accurato per effettuare una previsione.