Per quanto ne so, usiamo i punti storia per misurare la complessità di una storia in Scrum .
Ma che dire di Difetto ? Dovrebbe Difetto avere punti storia? In tal caso, cosa significa completare questi punti, dato che un Difetto non ha valore aziendale come una storia? Dovremmo avere qualcosa di diverso dai punti della storia, ad esempio, i punti di difetto?
[...] given that a Defect doesn't have business value like a story?
Non sono d'accordo con questo. Come utente, voglio che il mio prodotto software funzioni e funzioni come previsto. Un difetto noto va contro questo. Accumula e ignora abbastanza difetti e prima o poi i tuoi clienti smetteranno di usare il tuo prodotto e useranno invece qualcun altro.
Questo è qualcosa noto come mantenuto entrate 1 , che include i clienti che se ne andrebbero se qualcosa non viene soddisfatta dal cliente. Questo è spesso menzionato in termini di funzionalità, ma può anche includere difetti. (Puoi onestamente reclamare che il tuo prodotto abbia qualche caratteristica X se la suddetta funzione è rotta? Io non la penso così.)
Poiché si presume che quando una caratteristica o una storia viene accettata come "completata" funzioni come previsto, è perfettamente valido creare un'altra storia e stimarla nello stesso modo in cui si fa normalmente, specialmente se il difetto viene scoperto da il cliente (i) dopo il rilascio. Se il difetto è noto precedente per il rilascio, allora il proprietario del prodotto dovrebbe aver rifiutato lo stato "completato" per la storia e spostato su "In corso" o uno stato equivalente, ma non chiamare "fatto".
Should we have something different from story points, for example, defect points?
No. Trattalo come qualsiasi altra storia nel backlog del tuo team con una stima delle dimensioni per il suo sforzo / complessità e una priorità relativa ad altre storie.
Poiché i difetti sono un esempio di "Debito tecnico" e gli errori diventano più costosi da correggere, più la loro risoluzione viene posticipata dopo essere stata scoperta, il team e P.O. dovrebbe considerare la possibilità di dare ai difetti una priorità leggermente più alta. Quello che usi per determinare questa priorità (ad es. Visibilità, fastidio del cliente, qualcos'altro?) Dovrebbe essere di competenza della tua squadra.
Solo i miei 2 centesimi.
1 Stima e pianificazione agile, di M. Cohn
Direi che un difetto rappresenta una caratteristica precedente che non è stata adeguatamente completata. Pertanto, la fissazione dei difetti non fornisce punti storia.
Se applichi punti storia a difetti, la tua velocità di masterizzazione è ottima "Abbiamo completato 20 story point di funzionalità in questo sprint", ma 10 di questi punti erano correzioni di bug, quindi il tuo reale tasso di progresso è solo di 10 .
Ora, non sto sostenendo di correggere tutti i bug nello sprint subito dopo il rilevamento. Alcuni bug non sono così importanti. Ma non "completa" una feature di 5 punti, quindi lo sprint seguente fa altri 5 punti di bugfix: maschera male la stima, la cattiva codifica o entrambi.
La mia squadra ha inserito punti storia su qualsiasi difetto identificato dopo lo sprint in cui è stata completata la storia. Se il difetto viene rilevato durante lo sprint che la storia è in fase di sviluppo, consideriamo questi bug di accettazione e fanno parte della stima originale della storia.
Se stai collegando correttamente i difetti alle tue storie degli utenti (direttamente o indirettamente), allora dovresti avere la tracciabilità a ritroso. Quindi i punti della storia che sono interessati dal difetto sono il tuo riferimento. Da ciò, se hai già stimato la complessità / dimensione / sforzo di ciascun punto della storia che può aiutarti a stimare la complessità / dimensione / sforzo del difetto.
Sono stato in un paio di team di mischia in cui abbiamo discusso di questo, ma alla fine giungiamo alla conclusione che i difetti dovrebbero essere narrati come storie. Il motivo è lo scopo per cui utilizziamo i punti storia: misurando la quantità di punti storia completati a ogni sprint, possiamo ottenere una metrica approssimativa per la capacità della squadra, quanto lavoro il team può completare in uno sprint.
Se un difetto è abbastanza significativo da allontanare le risorse di sviluppo da altre storie, allora dovrebbe essere indicato e calcolato nella capacità della squadra per lo sprint. Ho sempre scoperto che una volta che lo sforzo di test è entrato nella discussione, che spesso include la scrittura di test mancati di unità / integrazione, finisce sempre per essere un lavoro abbastanza significativo da puntare. Se il bug è così ridicolmente piccolo e non è necessario un reale sforzo di test, puoi sempre assegnargli zero punti.
I punti storia rappresentano il valore del business e la velocità di cui una squadra è capace entro uno sprint. Sì, in un certo senso, l'errore bug ha un valore aziendale, ma se provi una capacità ad alta velocità solo perché hai messo i punti storia sui difetti, il tuo team trascurerà la garanzia della qualità.
Ad esempio, se una squadra ha una velocità ottimale di 30 piani per una pianificazione di sprint e dopo la loro cura si rende conto che può impegnarsi solo a 20 punti storia a causa di bug priorizzati dal proprietario del prodotto. Quindi solleva una bandiera per aumentare il controllo / gestione della qualità e l'obiettivo di ridurre la quantità di difetti.
Il dipartimento di ingegneria deve reagire, correggere e correggere eventuali problemi quando si nota una diminuzione della velocità.
Devi assegnare punti storia, altrimenti non hai modo di misurare con precisione la velocità delle squadre.
Se superi uno dei 50 punti in uno sprint, ma stai lavorando su 10 punti di bug, la tua velocità sarà solo di 40. Come faresti conto di questo nella prossima sprint planning?