Quali metriche usi nel tuo progetto Scrum? [chiuso]

Non tutti necessariamente "Scrum Specific" ma tieni presente che Scrum è un framework e non un sostituto per una buona pratica di Project Management :-) Suggerirei:

Funzioni aggiunte / dimostrate dall'ultimo rapporto - Molto interessante per dire agli azionisti cosa è già parte del prodotto!

Difetti che "scivolano" fuori dall'iterazione - questo è il tasso di difetti che vengono aggiunti al sistema. Idealmente, sarà pari a zero, il che indica che entrambi i test stanno accadendo prima che esistano i limiti di iterazione e qualsiasi debito tecnologico che il proprietario del prodotto ha accettato come parte dell'iterazione o si è insinuato nel sistema come debito tecnologico. Difficile da misurare e "fingere"

Definizione della squadra di fatto : segnala le eventuali modifiche apportate alla squadra mentre procede lo sprint. Questo è meno "numerico" ma è una buona indicazione che un team Scrum sta imparando mentre sviluppa il prodotto e sta adattando il loro modo di lavorare. Meno "intrusivo" che chiedere una relazione su "cosa è andato bene / cosa deve cambiare"

Burndown contro il backlog per il rilascio - Immagina un grafico ad area in pila (in Excel) il numero di punti con cui inizia il rilascio potrebbe essere 100, e ogni sprint 10 (ad esempio) si chiude e forse 5 vengono aggiunti. Mi piacciono circa 5-6 aree impilate: Accettato (chiuso), Rimosso (chiuso), Originale (aperto), Nuovo mancato (aperto), Nuovo dai clienti (aperto). Mostra questa iterazione e vedrai rapidamente come sta andando la squadra.

Scheda rischio : sempre sempre segnala sempre i rischi principali identificati dal team. Mi piace mostrare i primi 5 rischi in una vista quadrante - link

Data di spedizione prevista - Prepara gli stakeholder che le prime 2-3 iterazioni avranno ampie oscillazioni fino a quando la squadra non si assesterà su una velocità.

hth

La velocità è una metrica scadente per l'utilizzo da parte di chiunque al di fuori del team di Scrum, perché un punto storia non è un'unità fissa. È utile per stimare quanto si può sopportare nel prossimo sprint e per calcolare il burndown, ma se i membri del team vengono rimproverati a bassa velocità, aumenteranno le stime dei punti storia. Anche se non stai cercando di manipolarlo, la velocità può variare in modo significativo per una serie di altri motivi, come l'incertezza, la stima delle abilità che migliorano nel tempo o la stima delle abilità che diminuiscono temporaneamente quando si lavora con una tecnologia sconosciuta.

Secondo me, il burndown dovrebbe essere tutto ciò di cui hanno bisogno. Quale migliore metrica è lì che sapere se il tuo team è sulla buona strada per fornire le funzionalità che il business apprezza di più, nel momento in cui tali funzioni sono previste? Hanno anche l'opportunità di sederti con te ogni sprint e avere queste caratteristiche dimostrate di persona. Se la qualità sta iniziando a soffrire, loro lo sapranno se prendono sul serio la demo.

Ricorda che parte del manifesto agile è "Collaborazione del cliente per la negoziazione del contratto". Se lo stai facendo bene, non avranno bisogno di tanti numeri grezzi per valutare il tuo rendimento, perché possono valutare i tuoi progressi con i loro occhi.

Is there any other thing I can provide them in this regards? Have you got metrics other than velocity?

Test scritti / test passati.

Entrambe le linee sono (di solito) non-decrescenti.

Il cambiamento di pendenza indica un cambiamento di messa a fuoco. Altri test dovrebbero essere scritti all'inizio di uno sprint. Altri test dovrebbero essere passati nel mezzo dello sprint. Alcuni resistono alla risoluzione e durano fino alla fine. Alcuni non passano mai e vengono posticipati.

Quando il numero di test aumenta in ritardo in uno sprint indica che le cose stanno per essere scoperte. Entrambi gli User story erano incompleti (o fuorvianti) o la nuova tecnologia (e le nuove API) stanno introducendo nuovi scenari di test.

I test persistentemente non passeranno (o non verranno superati) indicano il codice fragile o un caso usato mal definito.

C'è molto da imparare dai conteggi dei test scritti-test-passati.

[If you found this "dismissive" in any way, please flag it. Apparently, my answers are "dismissive." I've been warned and you should feel free to flag my dismissive answers.]

Dal punto di vista del cliente, c'è solo una metrica di produttività che conta: valore di business fornito nel tempo. Presumibilmente, il Product Owner sta già valutando il valore commerciale relativo di ciascun articolo di backlog quando il backlog ha la priorità. Quindi dovrebbe essere relativamente facile avere un valore numerico assegnato a ogni elemento del backlog che rappresenta il suo valore commerciale.