In breve, dipende interamente da te.
MISCHIA
Entrambe le opzioni che menzioni sono valide, scegli solo quella più adatta alla tua squadra.
Se trascorri un periodo di tempo abbastanza prevedibile eseguendo lavori di manutenzione , quindi riduci la quantità di tempo disponibile per lo sprint in modo da avere più "overhead".
Se trovi che il tempo non può essere previsto , fallo diventare parte dello sprint backlog.
Per quello che vale, io uso Kanban ora
Non uso più gli sprint fissi perché quando ho iniziato a utilizzare SCRUM ho scoperto rapidamente che non mi stava aiutando. Ora utilizzo Kanban con un flusso di lavoro che ho sviluppato personalmente; le mie ragioni per questo erano triplici:
- Ho scoperto che l'organizzazione del lavoro attorno ai casi d'uso tendeva a disorientare l'analisi e la progettazione del dominio (fino al punto di non far parte del flusso di lavoro documentato).
- L'organizzazione intorno ai casi d'uso (come ti identifichi) non si adatta alle correzioni di bug, alle revisioni di spec / scope o ad altri lavori di vario genere.
- Trovo che sia più in grado di prevedere quando avrò una determinata funzione pronta piuttosto che avere una durata di sprint arbitraria (in genere di due settimane).
Sulle mie schede KanBan, i miei elementi di lavoro principali sono funzioni piuttosto che casi d'uso. Questi sono definiti da un processo di analisi a livello di dominio che identifica i casi d'uso, ne ricava le funzioni e le definisce come componenti.
Ho anche oggetti di lavoro più piccoli che sono collegati alla loro funzione genitore, questi sono: Revisioni (modifica dell'ambito di una funzione), Difetti (ovvero bug o deviazioni dai requisiti delle funzioni indicate), Stranezze (modifiche minori che non sono né delle altre).
Questo mi dà una buona visione di quanto lavoro di manutenzione devo fare nelle prossime settimane o due e quanto nuovo sviluppo.