Dovresti ricompensare in base alla completezza o alla velocità complessiva del progetto?

Ah, stai sparando a un bersaglio in movimento e ti aspetti che le persone fingano di stare in piedi!

Dovresti prendere una decisione su un bersaglio. Se il numero di biglietti rimanente è una metrica, è ingiusto aggiungere i biglietti, specialmente esternamente, in modo forzato.

In SCRUM quando è previsto uno sprint, la squadra si impegna al suo contenuto all'inizio, all'unanimità. Da quel momento il contenuto può essere modificato solo dal team stesso (o dallo sprint annullato). Altrimenti tu mandi fuori combattimento la squadra e uccidi ogni speranza di vero impegno.

Puoi adottare un'idea simile. O abbandonare quel sistema di targeting e premiare semplicemente uno sforzo salutare per risolvere i problemi, accettando di avere una quantità X di progressi, ma nel frattempo potrebbe aver esteso lo scopo del progetto di più.

D'altro canto, suggerisco di evitare il creep dello scope usando le milestone: aggiungi nuove cose al prossimo traguardo e potresti persino mantenere il punteggio metrico originale. Una volta completato il milestone, puoi pianificare il prossimo.

Consegnate in modo incrementale il sistema alla produzione? In caso contrario, inizierei a distribuire anche piccole parti del sistema può aiutare il morale e costruire un buon rapporto con il cliente. Effettuare queste consegne incrementali offrirà al team un orizzonte più breve su cui concentrarsi, aiutando l'obiettivo a sentirsi più raggiungibile.

Per quanto riguarda i premi, non premetterei in base alla velocità, mi viene in mente un vecchio cartone di Dilbert in cui il capo afferma che darà bonus per ogni bug risolto, dopo un po 'di celebrazione, Wally dichiara con orgoglio, "I vado a codificarmi un mini-van ". Premiando la velocità, ritengo che mandi il messaggio sbagliato al team, valutiamo le metriche sul software funzionante.

Cheers!

Se ti sei impegnato a utilizzare una metodologia SCRUM, avresti un Sprint Backlog fisso. È ben stabilito che, dovresti mantenere il backlog congelato per la durata dello sprint.

Se c'è un caso eccezionale per un ticket per darti una maggiore RoI includendolo in questo sprint dopo che il backlog è stato congelato, allora ha senso modificare il backlog. Tuttavia, se continui ad aggiungere elementi a un backlog durante lo sprint solo perché gli elementi vengono eliminati a una buona velocità, maschera il progresso e mina il processo.

Durante il ciclo di vita ci sarebbero molti biglietti creati e chiusi e il numero continuerebbe ad aumentare o diminuire durante questo periodo.

Il conteggio dei ticket risolti da solo non offre una visione della complessità, della criticità coinvolta nei problemi risolti. Se rimani bloccato su due biglietti complicati per uno sprint di 2 settimane, con la metrica del conteggio dei ticket chiusa, ti verrebbe attribuito un punteggio piuttosto basso.

Il conteggio dei ticket non dovrebbe essere la metrica. Incentivo dovrebbe essere dato alle versioni di funzionalità prive di bug in incrementi. E questi incrementi dovrebbero essere pianificati per uno sprint e il backlog congelato.